| Source Page | ADAMIG1DOT3:ADaMIG tables |
|---|---|
| Valid Tables | 28 |
| Destination | Library |
| Options |
|
| Output Format | Table |
| Class of Dataset | Dataset Name | Seq. for Order | Data Structure Name | CDISC Notesa | Data Structure Descriptiona | Data Structure Namea | SubClass of Dataset | CDISC Notes | Fragment | Variable Name | Variable Label | Type | Variable Grouping | Class | Core | Codelist/Controlled Terms |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SUBJECT LEVEL ANALYSIS DATASET | ADSL | 1 | ADSL | ADSL contains one record per subject, regardless of the type of clinical trial design. ADSL contains variables such as subject-level population flags, planned and actual treatment variables, demographic information, randomization factors, subgrouping variables, stratification factors, and important dates. ADSL is used to provide key facts about the subject that are analysis-enabling or which facilitate interpretation of analysis. The process for adding ADSL variables into BDS datasets is set by the producer of the datasets. | Subject-Level Analysis Dataset | |||||||||||
| BASIC DATA STRUCTURE | 1 | A BDS dataset contains one or more records per subject, per analysis parameter, per analysis timepoint. Analysis timepoint is conditionally required, depending on the analysis. In situations where there is no analysis timepoint, the structure is one or more records per subject per analysis parameter. | CDISC Basic Data Structure | BDS | ||||||||||||
| BASIC DATA STRUCTURE | 2 | Datasets in the SubClass TIME-TO-EVENT must have a Class of BASIC DATA STRUCTURE and meet all the principles of that class. A TTE dataset is used specifically for survival or time-to-event analyses and includes the following: (1) time from a defined starting point (e.g., the date of randomization or of an intervention) to the time of occurrence of the event of interest; and (2) an indication that a subject's time to event has been censored and for what reason. | Basic Data Structure Time-to-Event | TTE | TIME-TO- EVENT | |||||||||||
| 1 | Suffix used in names of grouping variables, where "y" refers to the grouping scheme or algorithm (not the category within the grouping). Note that GRy can be abbreviated to Gy when necessary to comply with the variable name length limit of 8 characters. The corresponding numeric version of the variable will use the suffix GRyN (or GyN if the Gy abbreviation is used). For more information on grouping variables see Section 3.1.1, General Variable Conventions. See Table 3.2.2 for examples of grouping variables. | GRy | ||||||||||||||
| 2 | Suffix used in names of character flag variables, when the valid values of the variable are Y/null or Y/N/null. The corresponding numeric version of the variable will use the suffix FN. For more information on flag variables, see Section 3.1.1, General Variable Conventions, and Section 3.1.4, Flag Variable Conventions. See Table 3.2.3, Table 3.3.4.3.1, and Table 3.3.8.1 for examples of flag variables. | FL | ||||||||||||||
| 3 | Suffix used in names of numeric date variables. For more information on timing variables, see Section 3.1.2, Timing Variable Conventions. See Section 3.3.3, Timing Variables for BDS Datasets, for examples of timing variables. | DT | ||||||||||||||
| 4 | Suffix used in names of numeric time variables. For more information on timing variables, see Section 3.1.2, Timing Variable Conventions. See Section 3.3.3, Timing Variables for BDS Datasets, for examples of timing variables. Note that although ADaM variable ARELTM ends in TM, it is an exception, and is not a numeric time variable. In addition, the SDTM variables --ELTM are not numeric time variables. | TM | ||||||||||||||
| 5 | Suffix used in names of numeric datetime variables. For more information on timing variables, see Section 3.1.2, Timing Variable Conventions. See Section 3.3.3, Timing Variables for BDS Datasets, for examples of timing variables. | DTM | ||||||||||||||
| 6 | Suffix used in names of date imputation flag variables. Note that DTF can be abbreviated to DF to comply with the variable name length limit of 8 characters. For more information, see Section 3.1.3, Date and Time Imputation Flag Variables. See Section 3.3.3, Timing Variables for BDS Datasets, for examples of timing imputation variables. | DTF | ||||||||||||||
| 7 | Suffix used in names of time imputation flag variables. Note that TMF can be abbreviated to TF to comply with the variable name length limit of 8 characters. For more information, see Section 3.1.3, Date and Time Imputation Flag Variables. See Section 3.3.3, Timing Variables for BDS Datasets, for examples of timing imputation variables. | TMF | ||||||||||||||
| 8 | Suffix used in names of relative day variables that do not include day 0. For more information on timing variables, see Section 3.1.2, Timing Variable Conventions. See Section 3.3.3, Timing Variables for BDS Datasets, for examples of timing variables. | DY | ||||||||||||||
| 1 | Baseline. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. \n Not to be used to support more than one baseline definition for AVAL in BDS datasets. See paragraph immediately following this table. | BL | ||||||||||||||
| 2 | Change. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. \n Not to be used to support change from more than one baseline for AVAL in BDS datasets. See paragraph immediately following this table. | CHG | ||||||||||||||
| 3 | Follow-up. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. | FU | ||||||||||||||
| 4 | On treatment. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. | OT | ||||||||||||||
| 5 | Run-in. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. | RU | ||||||||||||||
| 6 | Screening. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. | SC | ||||||||||||||
| 7 | Taper. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. | TA | ||||||||||||||
| 8 | Titer. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. | TI | ||||||||||||||
| 9 | Units. The position of this fragment is at the end of the variable, as a suffix. \n To identify the units for a variable, a separate variable can be created, using the name of the original variable with a "U" suffix added. To keep within the 8-character variable name length limit, some truncation may be necessary prior to appending the U. In situations where the units do not vary within the ADaM dataset, it may be preferable to simply include the units in the variable's label and metadata. The approach taken will be determined by the producer, based on the requirements of the analysis and review of the dataset. Note that there is no separate units variable for BDS variables PARAM or AVAL, since the units of AVAL will be included in the value of PARAM. | U | ||||||||||||||
| 10 | Washout. As described below, the position of this fragment within the variable name is dependent on the purpose of the variable. | WA | ||||||||||||||
| ADSL | 1 | DM.STUDYID | STUDYID | Study Identifier | Char | Identifier | ADSL | Req | ||||||||
| ADSL | 2 | DM.USUBJID | USUBJID | Unique Subject Identifier | Char | Identifier | ADSL | Req | ||||||||
| ADSL | 3 | DM.SUBJID. SUBJID is required in ADSL, but permissible in other datasets. | SUBJID | Subject Identifier for the Study | Char | Identifier | ADSL | Req | ||||||||
| ADSL | 4 | DM.SITEID. SITEID is required in ADSL, but permissible in other datasets. | SITEID | Study Site Identifier | Char | Identifier | ADSL | Req | ||||||||
| ADSL | 5 | Character description of a grouping or pooling of clinical sites for analysis purposes. For example, SITEGR3 is the name of a variable containing site group (pooled site) names, where the grouping has been done according to the third site grouping algorithm, defined in variable metadata; SITEGR3 does not mean the third group of sites. | SITEGRy | Pooled Site Group y | Char | Identifier | ADSL | Perm | ||||||||
| ADSL | 6 | Numeric representation of SITEGRy. There must be a one-to-one relationship between SITEGRyN and SITEGRy within a study. \n SITEGRyN cannot be present unless SITEGRy is also present. When SITEGRy and SITEGRyN are present, then on a given record, either both must be populated or both must be null. | SITEGRyN | Pooled Site Group y (N) | Num | Identifier | ADSL | Perm | ||||||||
| ADSL | 7 | Character description of geographical region. For example, REGION1 might have values of "Asia", "Europe", "North America", "Rest of World"; REGION2 might have values of "United States", "Rest of World". | REGIONy | Geographic Region y | Char | Identifier | ADSL | Perm | ||||||||
| ADSL | 8 | Numeric representation of REGIONy. Orders REGIONy for analysis and reporting.There must be a one-to-one relationship between REGIONyN and REGIONy within a study. \n REGIONyN cannot be present unless REGIONy is also present. When REGIONy and REGIONyN are present, then on a given record, either both must be populated or both must be null. | REGIONyN | Geographic Region y (N) | Num | Identifier | ADSL | Perm | ||||||||
| ADSL | 1 | DM.AGE. If analysis needs require a derived age that does not match DM.AGE, then AAGE must be added | AGE | Age | Num | Subject Demographics | ADSL | Req | ||||||||
| ADSL | 2 | DM.AGEU | AGEU | Age Units | Char | Subject Demographics | ADSL | Req | (AGEU) | |||||||
| ADSL | 3 | Character description of a grouping or pooling of the subject's age for analysis purposes. For example, AGEGR1 might have values of "<18", "18-65", and ">65"; AGEGR2 might have values of "Less than 35 y old" and "At least 35 y old". | AGEGRy | Pooled Age Group y | Char | Subject Demographics | ADSL | Perm | ||||||||
| ADSL | 4 | Numeric representation of AGEGRy. Orders the grouping or pooling of subject age for analysis and reporting. There must be a one-to-one relationship between AGEGRyN and AGEGRy within a study. \n AGEGRyN cannot be present unless AGEGRy is also present. When AGEGRy and AGEGRyN are present, then on a given record, either both must be populated or both must be null. | AGEGRyN | Pooled Age Group y (N) | Num | Subject Demographics | ADSL | Perm | ||||||||
| ADSL | 5 | Age used for analysis that may be derived differently than DM.AGE. AAGE is required if age is calculated differently than DM.AGE. | AAGE | Analysis Age | Num | Subject Demographics | ADSL | Cond | ||||||||
| ADSL | 6 | DM.SEX. | SEX | Sex | Char | Subject Demographics | ADSL | Req | (SEX) | |||||||
| ADSL | 7 | DM.RACE. | RACE | Race | Char | Subject Demographics | ADSL | Req | (RACE) | |||||||
| ADSL | 8 | Character description of a grouping or pooling of the subject's race for analysis purposes. | RACEGRy | Pooled Race Group y | Char | Subject Demographics | ADSL | Perm | ||||||||
| ADSL | 9 | Numeric representation of RACEGRy. Orders the grouping or pooling of subject race for analysis and reporting. There must be a one-to-one relationship between RACEGRyN and RACEGRy within a study. \n RACEGRyN cannot be present unless RACEGRy is also present. When RACEGRy and RACEGRyN are present, then on a given record, either both must be populated or both must be null. | RACEGRyN | Pooled Race Group y (N) | Num | Subject Demographics | ADSL | Perm | ||||||||
| ADSL | 1 | These flags identify whether or not the subject is included in the specified population. A minimum of one subject-level population flag variable is required in ADSL. \n Not all of the indicators listed here need to be included in ADSL. As stated in Section 3.1.4, Flag Variable Conventions, only those indicators corresponding to populations defined in the statistical analysis plan or populations used as a basis for analysis need be included in ADSL. \n This list of flags is not meant to be all-inclusive. Additional population flags may be added. \n The values of subject-level population flags cannot be blank. If a flag is used, the corresponding numeric version (*FN, where 0 = No and 1 = Yes) of the population flag can also be included. Please also refer to Section 3.1.4, Flag Variable Conventions. | FASFL | Full Analysis Set Population Flag | Char | Population Indicator | ADSL | Cond | Y, N | |||||||
| ADSL | 2 | These flags identify whether or not the subject is included in the specified population. A minimum of one subject-level population flag variable is required in ADSL. \n Not all of the indicators listed here need to be included in ADSL. As stated in Section 3.1.4, Flag Variable Conventions, only those indicators corresponding to populations defined in the statistical analysis plan or populations used as a basis for analysis need be included in ADSL. \n This list of flags is not meant to be all-inclusive. Additional population flags may be added. \n The values of subject-level population flags cannot be blank. If a flag is used, the corresponding numeric version (*FN, where 0 = No and 1 = Yes) of the population flag can also be included. Please also refer to Section 3.1.4, Flag Variable Conventions. | SAFFL | Safety Population Flag | Char | Population Indicator | ADSL | Cond | Y, N | |||||||
| ADSL | 3 | These flags identify whether or not the subject is included in the specified population. A minimum of one subject-level population flag variable is required in ADSL. \n Not all of the indicators listed here need to be included in ADSL. As stated in Section 3.1.4, Flag Variable Conventions, only those indicators corresponding to populations defined in the statistical analysis plan or populations used as a basis for analysis need be included in ADSL. \n This list of flags is not meant to be all-inclusive. Additional population flags may be added. \n The values of subject-level population flags cannot be blank. If a flag is used, the corresponding numeric version (*FN, where 0 = No and 1 = Yes) of the population flag can also be included. Please also refer to Section 3.1.4, Flag Variable Conventions. | ITTFL | Intent-To-Treat Population Flag | Char | Population Indicator | ADSL | Cond | Y, N | |||||||
| ADSL | 4 | These flags identify whether or not the subject is included in the specified population. A minimum of one subject-level population flag variable is required in ADSL. \n Not all of the indicators listed here need to be included in ADSL. As stated in Section 3.1.4, Flag Variable Conventions, only those indicators corresponding to populations defined in the statistical analysis plan or populations used as a basis for analysis need be included in ADSL. \n This list of flags is not meant to be all-inclusive. Additional population flags may be added. \n The values of subject-level population flags cannot be blank. If a flag is used, the corresponding numeric version (*FN, where 0 = No and 1 = Yes) of the population flag can also be included. Please also refer to Section 3.1.4, Flag Variable Conventions. | PPROTFL | Per-Protocol Population Flag | Char | Population Indicator | ADSL | Cond | Y, N | |||||||
| ADSL | 5 | These flags identify whether or not the subject is included in the specified population. A minimum of one subject-level population flag variable is required in ADSL. \n Not all of the indicators listed here need to be included in ADSL. As stated in Section 3.1.4, Flag Variable Conventions, only those indicators corresponding to populations defined in the statistical analysis plan or populations used as a basis for analysis need be included in ADSL. \n This list of flags is not meant to be all-inclusive. Additional population flags may be added. \n The values of subject-level population flags cannot be blank. If a flag is used, the corresponding numeric version (*FN, where 0 = No and 1 = Yes) of the population flag can also be included. Please also refer to Section 3.1.4, Flag Variable Conventions. | COMPLFL | Completers Population Flag | Char | Population Indicator | ADSL | Cond | Y, N | |||||||
| ADSL | 6 | These flags identify whether or not the subject is included in the specified population. A minimum of one subject-level population flag variable is required in ADSL. \n Not all of the indicators listed here need to be included in ADSL. As stated in Section 3.1.4, Flag Variable Conventions, only those indicators corresponding to populations defined in the statistical analysis plan or populations used as a basis for analysis need be included in ADSL. \n This list of flags is not meant to be all-inclusive. Additional population flags may be added. \n The values of subject-level population flags cannot be blank. If a flag is used, the corresponding numeric version (*FN, where 0 = No and 1 = Yes) of the population flag can also be included. Please also refer to Section 3.1.4, Flag Variable Conventions. | RANDFL | Randomized Population Flag | Char | Population Indicator | ADSL | Cond | Y, N | |||||||
| ADSL | 7 | These flags identify whether or not the subject is included in the specified population. A minimum of one subject-level population flag variable is required in ADSL. \n Not all of the indicators listed here need to be included in ADSL. As stated in Section 3.1.4, Flag Variable Conventions, only those indicators corresponding to populations defined in the statistical analysis plan or populations used as a basis for analysis need be included in ADSL. \n This list of flags is not meant to be all-inclusive. Additional population flags may be added. \n The values of subject-level population flags cannot be blank. If a flag is used, the corresponding numeric version (*FN, where 0 = No and 1 = Yes) of the population flag can also be included. Please also refer to Section 3.1.4, Flag Variable Conventions. | ENRLFL | Enrolled Population Flag | Char | Population Indicator | ADSL | Cond | Y, N | |||||||
| ADSL | 1 | DM.ARM | ARM | Description of Planned Arm | Char | Treatment | ADSL | Req | ||||||||
| ADSL | 2 | DM.ACTARM | ACTARM | Description of Actual Arm | Char | Treatment | ADSL | Perm | ||||||||
| ADSL | 3 | Subject-level identifier that represents the planned treatment for period xx. In a one-period randomized trial, TRT01P would be the treatment to which the subject was randomized. TRTxxP might be derived from the SDTM DM variable ARM. At least TRT01P is required. | TRTxxP | Planned Treatment for Period xx | Char | Treatment | ADSL | Req | ||||||||
| ADSL | 4 | Numeric representation of TRTxxP. There must be a one-to-one relationship between TRTxxPN and TRTxxP within a study. \n TRTxxPN cannot be present unless TRTxxP is also present. When TRTxxP and TRTxxPN are present, then on a given record, either both must be populated or both must be null. | TRTxxPN | Planned Treatment for Period xx (N) | Num | Treatment | ADSL | Perm | ||||||||
| ADSL | 5 | Subject-level identifier that represents the actual treatment for the subject for period xx. Required when actual treatment does not match planned and there is an analysis of the data as treated. | TRTxxA | Actual Treatment for Period xx | Char | Treatment | ADSL | Cond | ||||||||
| ADSL | 6 | Numeric representation of TRTxxA. There must be a one-to-one relationship between TRTxxAN and TRTxxA within a study. \n TRTxxAN cannot be present unless TRTxxA is also present. When TRTxxA and TRTxxAN are present, then on a given record, either both must be populated or both must be null. | TRTxxAN | Actual Treatment for Period xx (N) | Num | Treatment | ADSL | Perm | ||||||||
| ADSL | 7 | Required when there is an analysis based on the sequence of treatments, for example in a crossover design. TRTSEQP is not necessarily equal to ARM, for example if ARM contains elements that are not relevant to analysis of treatments or ARM is not fully descriptive (e.g., "GROUP 1," "GROUP 2"). When analyzing based on the sequence of treatments, TRTSEQP is required even if identical to ARM. | TRTSEQP | Planned Sequence of Treatments | Char | Treatment | ADSL | Cond | ||||||||
| ADSL | 8 | Numeric representation of TRTSEQP. There must be a one-to-one relationship between TRTSEQPN and TRTSEQP within a study. \n TRTSEQPN cannot be present unless TRTSEQP is also present. When TRTSEQP and TRTSEQPN are present, then on a given record, either both must be populated or both must be null. | TRTSEQPN | Planned Sequence of Treatments (N) | Num | Treatment | ADSL | Perm | ||||||||
| ADSL | 9 | TRTSEQA is required if a situation occurred in the conduct of the trial where a subject received a sequence of treatments other than what was planned and there is an analysis based on the sequence of treatments. | TRTSEQA | Actual Sequence of Treatments | Char | Treatment | ADSL | Cond | ||||||||
| ADSL | 10 | Numeric representation of TRTSEQA. There must be a one-to-one relationship between TRTSEQAN and TRTSEQA within a study. \n TRTSEQAN cannot be present unless TRTSEQA is also present. When TRTSEQA and TRTSEQAN are present, then on a given record, either both must be populated or both must be null. | TRTSEQAN | Actual Sequence of Treatments (N) | Num | Treatment | ADSL | Perm | ||||||||
| ADSL | 11 | Planned pooled treatment y for period xx. Useful when planned treatments (TRTxxP) in the specified period xx are pooled together for analysis according to pooling algorithm y. For example when in period 2 the first pooling algorithm dictates that all doses of Drug A (TR02PG1="All doses of Drug A") are pooled together for comparison to all doses of Drug B (TR02PG1="All doses of Drug B"). Each value of TRTxxP is pooled within at most one value of TRxxPGy. | TRxxPGy | Planned Pooled Treatment y for Period xx | Char | Treatment | ADSL | Perm | ||||||||
| ADSL | 12 | Numeric representation of TRxxPGy. There must be a one-to-one relationship between TRxxPGyN and TRxxPGy within a study. \n TRxxPGyN cannot be present unless TRxxPGy is also present. When TRxxPGy and TRxxPGyN are present, then on a given record, either both must be populated or both must be null. | TRxxPGyN | Planned Pooled Trt y for Period xx (N) | Num | Treatment | ADSL | Perm | ||||||||
| ADSL | 13 | Actual pooled treatment y for period xx. Required when TRxxPGy is present and TRTxxA is present. | TRxxAGy | Actual Pooled Treatment y for Period xx | Char | Treatment | ADSL | Cond | ||||||||
| ADSL | 14 | Numeric representation of TRxxAGy. There must be a one-to-one relationship between TRxxAGyN and TRxxAGy within a study. \n TRxxAGyN cannot be present unless TRxxAGy is also present. When TRxxAGy and TRxxAGyN are present, then on a given record, either both must be populated or both must be null. | TRxxAGyN | Actual Pooled Trt y for Period xx (N) | Num | Treatment | ADSL | Perm | ||||||||
| ADSL | 15 | Planned pooled treatment sequence y. Useful when planned treatment sequences (TRTSEQP) are pooled together for analysis according to pooling algorithm y. For example, this might be used in an analysis of an extension study when the analysis is based on what the subject received in the parent study as well as in the extension study. | TSEQPGy | Planned Pooled Treatment Sequence y | Char | Treatment | ADSL | Perm | ||||||||
| ADSL | 16 | Numeric representation of TSEQPGy. There must be a one-to-one relationship between TSEQPGyN and TSEQPGy within a study. \n TSEQPGyN cannot be present unless TSEQPGy is also present. When TSEQPGy and TSEQPGyN are present, then on a given record, either both must be populated or both must be null. | TSEQPGyN | Planned Pooled Treatment Sequence y (N) | Num | Treatment | ADSL | Perm | ||||||||
| ADSL | 17 | Actual pooled treatment sequence y. Required when TSEQPGy is present and TRTSEQA is present. | TSEQAGy | Actual Pooled Treatment Sequence y | Char | Treatment | ADSL | Cond | ||||||||
| ADSL | 18 | Numeric representation of TSEQAGy. There must be a one-to-one relationship between TSEQAGyN and TSEQAGy within a study. \n TSEQAGyN cannot be present unless TSEQAGy is also present. When TSEQAGy and TSEQAGyN are present, then on a given record, either both must be populated or both must be null. | TSEQAGyN | Actual Pooled Treatment Sequence y (N) | Num | Treatment | ADSL | Perm | ||||||||
| ADSL | 1 | Subject-level identifier that represents the planned treatment dosage for period xx. | DOSExxP | Planned Treatment Dose for Period xx | Num | Dose | ADSL | Perm | ||||||||
| ADSL | 2 | Subject-level identifier that represents the actual treatment dosage for period xx. | DOSExxA | Actual Treatment Dose for Period xx | Num | Dose | ADSL | Perm | ||||||||
| ADSL | 3 | The units for DOSExxP and DOSExxA. It is permissible to use suffixes such as "P" and "A" if needed, with labels modified accordingly. | DOSExxU | Units for Dose for Period xx | Char | Dose | ADSL | Perm | ||||||||
| ADSL | 1 | Date of first exposure to treatment for a subject in a study. TRTSDT and/or TRTSDTM are required if there is an investigational product. Note that TRTSDT is not required to have the same value as the SDTM DM variable RFXSTDTC. While both of these dates reflect the concept of first exposure, the ADaM date may be derived to support the analysis which may not necessarily be the very first date in the SDTM EX domain. | TRTSDT | Date of First Exposure to Treatment | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 2 | Time of first exposure to treatment for a subject in a study. | TRTSTM | Time of First Exposure to Treatment | Num | Treatment Timing | ADSL | Perm | ||||||||
| ADSL | 3 | Datetime of first exposure to treatment for a subject in a study. TRTSDT and/or TRTSDTM are required if there is an investigational product. | TRTSDTM | Datetime of First Exposure to Treatment | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 4 | The level of imputation of date of first exposure to treatment. If TRTSDT (or the date part of TRTSDTM) was imputed, TRTSDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | TRTSDTF | Date of First Exposure Imput. Flag | Char | Treatment Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 5 | The level of imputation of time of first exposure to treatment. If TRTSTM (or the time part of TRTSDTM) was imputed, TRTSTMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | TRTSTMF | Time of First Exposure Imput. Flag | Char | Treatment Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 6 | Date of last exposure to treatment for a subject in a study. TRTEDT and/or TRTEDTM are required if there is an investigational product. Note that TRTEDT is not required to have the same value as the SDTM DM variable RFXENDTC. While both of these dates reflect the concept of last exposure, the ADaM date may be derived to support the analysis which may not necessarily be the very last date in the SDTM EX domain. | TRTEDT | Date of Last Exposure to Treatment | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 7 | Time of last exposure to treatment for a subject in a study. | TRTETM | Time of Last Exposure to Treatment | Num | Treatment Timing | ADSL | Perm | ||||||||
| ADSL | 8 | Datetime of last exposure to treatment for a subject in a study. TRTEDT and/or TRTEDTM are required if there is an investigational product. | TRTEDTM | Datetime of Last Exposure to Treatment | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 9 | The level of imputation of date of last exposure to treatment. If TRTEDT (or the date part of TRTEDTM) was imputed, TRTEDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | TRTEDTF | Date of Last Exposure Imput. Flag | Char | Treatment Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 10 | The level of imputation of time of last exposure to treatment. If TRTETM (or the time part of TRTEDTM) was imputed, TRTETMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | TRTETMF | Time of Last Exposure Imput. Flag | Char | Treatment Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 11 | Date of first exposure to treatment in period xx. TRxxSDT and/or TRxxSDTM are only required in trial designs where multiple treatment periods are defined (i.e., required when there is a TRTxxP other than TRT01P). Examples include crossover designs or designs where multiple periods exist for the same treatment. | TRxxSDT | Date of First Exposure in Period xx | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 12 | Starting time of exposure to treatment in period xx. TRxxSTM and/or TRxxSDTM are only required in trial designs where starting time is important to the analysis and multiple treatment periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | TRxxSTM | Time of First Exposure in Period xx | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 13 | Datetime of first exposure to treatment in period xx. TRxxSDTM is only required in trial designs where multiple treatment periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | TRxxSDTM | Datetime of First Exposure in Period xx | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 14 | The level of imputation of date of first exposure to treatment in period xx. If TRxxSDT (or the date part of TRxxSDTM) was imputed, TRxxSDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | TRxxSDTF | Date 1st Exposure Period xx Imput. Flag | Char | Treatment Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 15 | The level of imputation of time of first exposure to treatment in period xx. If TRxxSTM (or the time part of TRxxSDTM) was imputed, TRxxSTMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | TRxxSTMF | Time 1st Exposure Period xx Imput. Flag | Char | Treatment Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 16 | Date of last exposure to treatment in period xx. TRxxEDT and/or TRxxEDTM are only required in trial designs where multiple treatment periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | TRxxEDT | Date of Last Exposure in Period xx | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 17 | Ending time of exposure to treatment in period xx. TRxxETM and/or TRxxEDTM are only required in trial designs where ending time is important to the analysis and multiple treatment periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | TRxxETM | Time of Last Exposure in Period xx | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 18 | Datetime of last exposure to treatment in period xx. TRxxEDTM is only required in trial designs where multiple treatment periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | TRxxEDTM | Datetime of Last Exposure in Period xx | Num | Treatment Timing | ADSL | Cond | ||||||||
| ADSL | 19 | The level of imputation of date of last exposure to treatment in period xx. If TRxxEDT (or the date part of TRxxEDTM) was imputed, TRxxEDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | TRxxEDTF | Date Last Exposure Period xx Imput. Flag | Char | Treatment Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 20 | The level of imputation of time of last exposure to treatment in period xx. If TRxxETM (or the time part of TRxxEDTM) was imputed, TRxxETMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | TRxxETMF | Time Last Exposure Period xx Imput. Flag | Char | Treatment Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 1 | The starting date of period xx. | APxxSDT | Period xx Start Date | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 2 | The starting time of period xx. | APxxSTM | Period xx Start Time | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 3 | The starting datetime of period xx. | APxxSDTM | Period xx Start Datetime | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 4 | The level of imputation of period xx start date. See Section 3.1.3, Date and Time Imputation Flag Variables. | APxxSDTF | Period xx Start Date Imput. Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 5 | The level of imputation of period xx start time. See Section 3.1.3, Date and Time Imputation Flag Variables. | APxxSTMF | Period xx Start Time Imput. Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 6 | The ending date of period xx. | APxxEDT | Period xx End Date | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 7 | The ending time of period xx. | APxxETM | Period xx End Time | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 8 | The ending datetime of period xx. | APxxEDTM | Period xx End Datetime | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 9 | The level of imputation of period xx end date. See Section 3.1.3, Date and Time Imputation Flag Variables. | APxxEDTF | Period xx End Date Imput. Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 10 | The level of imputation of period xx end time. See Section 3.1.3, Date and Time Imputation Flag Variables. | APxxETMF | Period xx End Time Imput. Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 11 | Description of analysis subperiod w within period xx. | PxxSw | Description of Period xx Subperiod w | Char | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 12 | The starting date of subperiod w within period xx. | PxxSwSDT | Period xx Subperiod w Start Date | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 13 | The starting time of subperiod w within period xx. | PxxSwSTM | Period xx Subperiod w Start Time | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 14 | The starting datetime of subperiod w within period xx. | PxxSwSDM | Period xx Subperiod w Start Datetime | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 15 | The level of imputation of the start date for subperiod w within period xx. See Section 3.1.3, Date and Time Imputation Flag Variables. | PxxSwSDF | Period xx Subper w Start Date Imput Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 16 | The level of imputation of the start time for subperiod w within period xx. See Section 3.1.3, Date and Time Imputation Flag Variables. | PxxSwSTF | Period xx Subper w Start Time Imput Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 17 | The ending date of subperiod w within period xx. | PxxSwEDT | Period xx Subperiod w End Date | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 18 | The ending time of subperiod w within period xx. | PxxSwETM | Period xx Subperiod w End Time | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 19 | The ending datetime of subperiod w within period xx. | PxxSwEDM | Period xx Subperiod w End Datetime | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 20 | The level of imputation of the end date for subperiod w within period xx. See Section 3.1.3, Date and Time Imputation Flag Variables. | PxxSwEDF | Period xx Subper w End Date Imput Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 21 | The level of imputation of the end time for subperiod w within period xx. See Section 3.1.3, Date and Time Imputation Flag Variables. | PxxSwETF | Period xx Subper w End Time Imput Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 22 | Description of analysis phase w. Analysis phase is independent of TRTxxP within ADSL, and may be populated for spans of time where a subject is not on treatment. | APHASEw | Description of Phase w | Char | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 23 | The starting date of phase w. | PHwSDT | Phase w Start Date | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 24 | The starting time of phase w. | PHwSTM | Phase w Start Time | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 25 | The starting datetime of phase w. | PHwSDTM | Phase w Start Datetime | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 26 | The level of imputation of the start date for phase w. See Section 3.1.3, Date and Time Imputation Flag Variables. | PHwSDTF | Phase w Start Date Imputation Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 27 | The level of imputation of the start time for phase w. See Section 3.1.3, Date and Time Imputation Flag Variables. | PHwSTMF | Phase w Start Time Imputation Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 28 | The ending date of phase w. | PHwEDT | Phase w End Date | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 29 | The ending time of phase w. | PHwETM | Phase w End Time | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 30 | The ending datetime of phase w. | PHwEDTM | Phase w End Datetime | Num | Period, Subperiod, and Phase Timing | ADSL | Perm | ||||||||
| ADSL | 31 | The level of imputation of the end date for phase w. See Section 3.1.3, Date and Time Imputation Flag Variables. | PHwEDTF | Phase w End Date Imputation Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 32 | The level of imputation of the end time for phase w. See Section 3.1.3, Date and Time Imputation Flag Variables. | PHwETMF | Phase w End Time Imputation Flag | Char | Period, Subperiod, and Phase Timing | ADSL | Cond | (TIMEFL) | |||||||
| ADSL | 1 | The subject's status as of the end of study or data cutoff. Examples: COMPLETED, DISCONTINUED, ONGOING. | EOSSTT | End of Study Status | Char | Trial Experience | ADSL | Perm | (SBJTSTAT) | |||||||
| ADSL | 2 | Date subject ended the study - either date of completion or date of discontinuation or data cutoff date for interim analyses. | EOSDT | End of Study Date | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 3 | Reason for subject's discontinuation from study. The source would most likely be the SDTM DS dataset. Null for subjects who completed the study. | DCSREAS | Reason for Discontinuation from Study | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 4 | Additional detail regarding subject's discontinuation from study (e.g., description of "other"). | DCSREASP | Reason Spec for Discont from Study | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 5 | The subject's status as of the end of treatment or data cutoff. Examples: COMPLETED, DISCONTINUED, ONGOING. | EOTSTT | End of Treatment Status | Char | Trial Experience | ADSL | Perm | (SBJTSTAT) | |||||||
| ADSL | 6 | If a subject discontinued treatment in the study, then this variable indicates the reason for discontinuation. This is for discontinuation of treatment in the overall study and not to be used for discontinuation reason within individual treatment periods. | DCTREAS | Reason for Discontinuation of Treatment | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 7 | Additional detail regarding subject's discontinuation from treatment (e.g., description of "other"). | DCTREASP | Reason Specify for Discont of Treatment | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 8 | The subject's treatment status as of the end of period xx, or data cutoff if within period xx. Examples: COMPLETED, DISCONTINUED, ONGOING. | EOTxxSTT | End of Treatment Status in Period xx | Char | Trial Experience | ADSL | Perm | (SBJTSTAT) | |||||||
| ADSL | 9 | Reason for discontinuing treatment in period xx. | DCTxxRS | Reason for Discont of Treat in Period xx | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 10 | Additional detail regarding subject's discontinuation of treatment in period xx (e.g., description of "other"). | DCTxxRSP | Reason Spec for Disc of Trt in Period xx | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 11 | The subject's status as of the end of period xx, or data cutoff if within period xx. Examples: COMPLETED, DISCONTINUED, ONGOING. | EOPxxSTT | End of Period xx Status | Char | Trial Experience | ADSL | Perm | (SBJTSTAT) | |||||||
| ADSL | 12 | Reason for discontinuing analysis period xx. | DCPxxRS | Reason for Discont from Period xx | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 13 | Additional detail regarding subject's discontinuation from period xx (e.g., description of "other"). | DCPxxRSP | Reason Spec for Discont from Period xx | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 14 | Date subject gave informed consent. Generally equivalent to DM.RFICDTC. | RFICDT | Date of Informed Consent | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 15 | Date of subject's enrollment into trial. | ENRLDT | Date of Enrollment | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 16 | Required in randomized trials. | RANDDT | Date of Randomization | Num | Trial Experience | ADSL | Cond | ||||||||
| ADSL | 17 | This variable may be used in the case where there are multiple consent dates within a study. This date does not need to repeat the date in RFICDT. "y" can start with 1 but it is not required to start with 1. | RFICyDT | Date of Informed Consent y | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 18 | This variable may be used in the case where there are multiple enrollment dates within a study. This date does not need to repeat the date in ENRLDT. "y" can start with 1 but it is not required to start with 1. | ENRLyDT | Date of Enrollment y | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 19 | This variable may be used in the case where there are multiple randomization dates within a study. This date does not need to repeat the date in RANDDT. "y" can start with 1 but it is not required to start with 1. | RANDyDT | Date of Randomization y | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 20 | If this variable is included in ADSL, the best practice is to populate it for everyone. If the derivation for subjects who died differs from the derivation for subjects who are not known to have died, the differences should be noted in metadata. | LSTALVDT | Date Last Known Alive | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 21 | Overall percent compliance with treatment in the trial. TRCMP may be useful for inclusion in ADSL for reasons such as defining subgroups and/or populations. | TRCMP | Treatment Compliance (%) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 22 | Grouping "y" of TRCMP, treatment compliance percentage. | TRCMPGy | Treatment Compliance (%) Group y | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 23 | Numeric representation of treatment compliance (%) grouping "y". There must be a one-to-one relationship between TRCMPGyN and TRCMPGy within a study. \n TRCMPGyN cannot be present unless TRCMPGy is also present. When TRCMPGy and TRCMPGyN are present, then on a given record, either both must be populated or both must be null. | TRCMPGyN | Treatment Compliance (%) Group y (N) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 24 | Treatment duration for period xx as measured in days. More than one of TRxxDURD, TRxxDURM, and TRxxDURY can be populated, but each represents the entire duration in its respective units. | TRxxDURD | Treatment Duration in Period xx (Days) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 25 | Treatment duration for period xx, as measure in months. More than one of TRxxDURD, TRxxDURM, and TRxxDURY can be populated, but each represents the entire duration in its respective units. | TRxxDURM | Treatment Duration in Period xx (Months) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 26 | Treatment duration for period xx, as measured in years. More than one of TRxxDURD, TRxxDURM, and TRxxDURY can be populated, but each represents the entire duration in its respective units. | TRxxDURY | Treatment Duration in Period xx (Years) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 27 | Total treatment duration, as measured in days. More than one of TRTDURD, TRTDURM, and TRTDURY can be populated, but each represents the entire duration in its respective units. | TRTDURD | Total Treatment Duration (Days) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 28 | Total treatment duration, as measured in months. More than one of TRTDURD, TRTDURM, and TRTDURY can be populated, but each represents the entire duration in its respective units. | TRTDURM | Total Treatment Duration (Months) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 29 | Total treatment duration, as measured in years. More than one of TRTDURD, TRTDURM, and TRTDURY can be populated, but each represents the entire duration in its respective units. | TRTDURY | Total Treatment Duration (Years) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 30 | Date of subject's death. Derived from DM.DTHDTC. | DTHDT | Date of Death | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 31 | Imputation flag for date of subject's death. If DTHDT was imputed, DTHDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | DTHDTF | Date of Death Imputation Flag | Char | Trial Experience | ADSL | Cond | (DATEFL) | |||||||
| ADSL | 32 | Cause of Death. | DTHCAUS | Cause of Death | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 33 | Numeric representation of cause of death. There must be a one-to-one relationship between DTHCAUSN and DTHCAUS within a study. \n DTHCAUSN cannot be present unless DTHCAUS is also present. When DTHCAUS and DTHCAUSN are present, then on a given record, either both must be populated or both must be null. | DTHCAUSN | Cause of Death (N) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 34 | Grouping "y" of DTHCAUS, the subject's cause of death. | DTHCGRy | Cause of Death Group y | Char | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 35 | Numeric representation of grouping "y" of the subject's cause of death. There must be a one-to-one relationship between DTHCGRyN and DTHCGRy within a study. \n DTHCGyN cannot be present unless DTHCGy is also present. When DTHCGy and DTHCGyN are present, then on a given record, either both must be populated or both must be null. | DTHCGRyN | Cause of Death Group y (N) | Num | Trial Experience | ADSL | Perm | ||||||||
| ADSL | 1 | STRATAR contains the combination of values of the individual stratification factors used for randomization. The exact format should be determined by the sponsor. \n This variable is intended for studies that use stratified randomization. \n For example, ">=50, Treatment experienced, N" | STRATAR | Strata Used for Randomization | Char | Stratification | ADSL | Perm | ||||||||
| ADSL | 2 | Numeric representation of STRATAR. For example, STRATARN=3 when STRATAR=">=50, Treatment experienced, N". There must be a one-to-one relationship between STRATARN and STRATAR within a study. \n STRATARN cannot be present unless STRATAR is also present. When STRATAR and STRATARN are present, then on a given record, either both must be populated or both must be null. | STRATARN | Strata Used for Randomization (N) | Num | Stratification | ADSL | Perm | ||||||||
| ADSL | 3 | STRATwD is a full text description of the stratification factor "w". This text description will remain constant for all subjects. These descriptive variables are included to quickly and clearly communicate critical study design information as well as to facilitate integration. \n For example, STRAT3D="Hypertension" | STRATwD | Description of Stratification Factor w | Char | Stratification | ADSL | Perm | ||||||||
| ADSL | 4 | STRATwR is the subject-level value of the "w'th" stratification factor used for randomization. \n For example, STRAT3R="N" | STRATwR | Strat Factor w Value Used for Rand | Char | Stratification | ADSL | Perm | ||||||||
| ADSL | 5 | Numeric representation of STRATwR. For example, STRAT3RN=0 when STRAT3R="N". There must be a one-to-one relationship between STRATwRN and STRATwR within a study. \n STRATwRN cannot be present unless STRATwR is also present. When STRATwR and STRATwRN are present, then on a given record, either both must be populated or both must be null. | STRATwRN | Strat Factor w Value Used for Rand (N) | Num | Stratification | ADSL | Perm | ||||||||
| ADSL | 6 | STRATAV contains the entire string value represents the combination of values of the individual stratification factors that should have been used and represents the "as verified" value. The STRATAV variables are based on the source documentation and are determined after randomization. If the values used for the randomization of a given subject were all correct, then STRATAV will equal STRATAR. Otherwise, one or more components of the text string for STRATAR and STRATAV will be different. \n The exact format should be determined by the sponsor. \n For example, ">=50, Treatment experienced, Y" | STRATAV | Strata from Verification Source | Char | Stratification | ADSL | Perm | ||||||||
| ADSL | 7 | Numeric representation of STRATAV. For example, STRATAVN=4 when STRATVR=">=50, Treatment experienced, Y". There must be a one-to-one relationship between STRATAVN and STRATAV within a study. \n STRATAVN cannot be present unless STRATAV is also present. When STRATAV and STRATAVN are present, then on a given record, either both must be populated or both must be null. | STRATAVN | Strata from Verification Source (N) | Num | Stratification | ADSL | Perm | ||||||||
| ADSL | 8 | STRATwV is the "as verified" subject-level value of the "w'th" stratification factor. If the value based on randomization was correct, then STRATwV will equal STRATwR. \n For example, STRAT3V="Y" | STRATwV | Strat Factor w Value from Verif Source | Char | Stratification | ADSL | Perm | ||||||||
| ADSL | 9 | Numeric representation of STRATwV. For example, STRAT3VN=1 when STRAT3V="Y". There must be a one-to-one relationship between STRATwVN and STRATwV within a study. \n STRATwVN cannot be present unless STRATwV is also present. When STRATwV and STRATwVN are present, then on a given record, either both must be populated or both must be null. \n | STRATwVN | Strat Fact w Val from Verif Source (N) | Num | Stratification | ADSL | Perm | ||||||||
| 1 | DM.STUDYID, ADSL STUDYID, and/or STUDYID from another ADaM or SDTM dataset appropriate to the analysis. | STUDYID | Study Identifier | Char | Identifier | BDS | Req | |||||||||
| 2 | DM.USUBJID, ADSL.USUBJID, and/or USUBJID from another ADaM or SDTM dataset appropriate to the analysis. | USUBJID | Unique Subject Identifier | Char | Identifier | BDS | Req | |||||||||
| 3 | DM.SUBJID, ADSL.SUBJID, and/or SUBJID from another ADaM dataset appropriate to the analysis. SUBJID is required in ADSL, but permissible in other datasets. | SUBJID | Subject Identifier for the Study | Char | Identifier | BDS | Perm | |||||||||
| 4 | DM.SITEID, ADSL.SITEID, and/or SITEID from another ADaM dataset appropriate to the analysis. SITEID is required in ADSL, but permissible in other datasets. | SITEID | Study Site Identifier | Char | Identifier | BDS | Perm | |||||||||
| 5 | Sequence number given to ensure uniqueness of subject records within an ADaM dataset. As long as values are unique within a subject within the dataset, any valid number can be used for ASEQ. ASEQ uniquely indexes records within a subject within an ADaM dataset. \n ASEQ is useful for traceability when the dataset is used as input to another ADaM dataset. To refer to a record in a predecessor ADaM dataset, set SRCDOM to the name of the predecessor dataset, and set SRCSEQ to the value of ASEQ in the predecessor dataset. | ASEQ | Analysis Sequence Number | Num | Identifier | BDS | Perm | |||||||||
| 1 | TRTP is a record-level identifier that represents the planned treatment attributed to a record for analysis purposes. TRTP indicates how treatment varies by record within a subject and enables analysis of crossover and other designs. Though there is no requirement that TRTP will correspond to the TRTxxP as defined by the record's value of APERIOD, if populated, TRTP must match at least one value of the character planned treatment variables in ADSL (e.g., TRTxxP, TRTSEQP, TRxxPGy). \n As noted previously, at least one treatment variable is required even in non-randomized trials. This requirement is satisfied by any subject-level or record-level treatment variables (e.g., TRTxxP, TRTP, TRTA). Even if not used for analysis, any ADSL treatment variable may be included in the BDS dataset. | TRTP | Planned Treatment | Char | Record-Level Treatment | BDS | Cond | |||||||||
| 2 | Numeric representation of TRTP. There must be a one-to-one relationship between TRTPN and TRTP within a study. \n TRTPN cannot be present unless TRTP is also present. When TRTP and TRTPN are present, then on a given record, either both must be populated or both must be null. | TRTPN | Planned Treatment (N) | Num | Record-Level Treatment | BDS | Perm | |||||||||
| 3 | TRTA is a record-level identifier that represents the actual treatment attributed to a record for analysis purposes. TRTA indicates how treatment varies by record within a subject and enables analysis of crossover and other multi-period designs. Though there is no requirement that TRTA will correspond to the TRTxxA as defined by the record's value of APERIOD, TRTA must match at least one value of the character actual treatment variables in ADSL (e.g., TRTxxA, TRTSEQA, TRxxAGy). \n As noted previously, at least one treatment variable is required. This requirement is satisfied by any subject-level or record-level treatment variables (e.g., TRTxxP, TRTP, TRTA). Even if not used for analysis, any ADSL treatment variable may be included in the BDS dataset. | TRTA | Actual Treatment | Char | Record-Level Treatment | BDS | Cond | |||||||||
| 4 | Numeric representation of TRTA. There must be a one-to-one relationship between TRTAN and TRTA within a study. \n TRTAN cannot be present unless TRTA is also present. When TRTA and TRTAN are present, then on a given record, either both must be populated or both must be null. | TRTAN | Actual Treatment (N) | Num | Record-Level Treatment | BDS | Perm | |||||||||
| 5 | TRTPGy is the planned pooled treatment y attributed to a record for analysis purposes. "y" represents an integer [1-99, not zero-padded] corresponding to a particular pooling scheme. Useful when planned treatments (TRTP) are pooled together for analysis, for example when all doses of Drug A (TRTPG1=All doses of Drug A) are compared to all doses of Drug B (TRTPG1=All doses of Drug B). Each value of TRTP is pooled within at most one value of TRTPGy. | TRTPGy | Planned Pooled Treatment y | Char | Record-Level Treatment | BDS | Perm | |||||||||
| 6 | Numeric representation of TRTPGy. There must be a one-to-one relationship between TRTPGyN and TRTPGy within a study. \n TRTPGyN cannot be present unless TRTPGy is also present. When TRTPGy and TRTPGyN are present, then on a given record, either both must be populated or both must be null. | TRTPGyN | Planned Pooled Treatment y (N) | Num | Record-Level Treatment | BDS | Perm | |||||||||
| 7 | TRTAGy is the actual pooled treatment y attributed to a record for analysis purposes. "y" represents an integer [1-99, not zero-padded] corresponding to a particular pooling scheme. Required when TRTPGy is present and TRTA is present. | TRTAGy | Actual Pooled Treatment y | Char | Record-Level Treatment | BDS | Cond | |||||||||
| 8 | Numeric representation of TRTAGy. There must be a one-to-one relationship between TRTAGyN and TRTAGy within a study. \n TRTAGyN cannot be present unless TRTAGy is also present. When TRTAGy and TRTAGyN are present, then on a given record, either both must be populated or both must be null. | TRTAGyN | Actual Pooled Treatment y (N) | Num | Record-Level Treatment | BDS | Perm | |||||||||
| 1 | DOSEP represents the planned treatment dosage associated with the record. | DOSEP | Planned Treatment Dose | Num | Record-Level Dose | BDS | Perm | |||||||||
| 2 | Cumulative planned dosage of treatment for the subject at the point in time of the record (e.g., ADT). | DOSCUMP | Cumulative Planned Treatment Dose | Num | Record-Level Dose | BDS | Perm | |||||||||
| 3 | DOSEA represents the actual treatment dosage associated with the record. | DOSEA | Actual Treatment Dose | Num | Record-Level Dose | BDS | Perm | |||||||||
| 4 | Cumulative actual dosage of treatment for the subject at the point in time of the record (e.g., ADT). | DOSCUMA | Cumulative Actual Treatment Dose | Num | Record-Level Dose | BDS | Perm | |||||||||
| 5 | The units for DOSEP, DOSCUMP, DOSEA, and DOSCUMA. It is permissible to use suffixes such as "P" and "A" if needed, with labels modified accordingly. | DOSEU | Treatment Dose Units | Char | Record-Level Dose | BDS | Perm | |||||||||
| 1 | The date associated with AVAL and/or AVALC in numeric format. | ADT | Analysis Date | Num | Timing | BDS | Cond | |||||||||
| 2 | The time associated with AVAL and/or AVALC in numeric format. | ATM | Analysis Time | Num | Timing | BDS | Cond | |||||||||
| 3 | The datetime associated with AVAL and/or AVALC in numeric format. | ADTM | Analysis Datetime | Num | Timing | BDS | Cond | |||||||||
| 4 | The relative day of AVAL and/or AVALC. The number of days from an anchor date (not necessarily DM.RFSTDTC) to ADT. See Section 3.1.2, Timing Variable Conventions. If a dataset contains more than one record per parameter per subject, then an SDTM or ADaM relative timing variable must be present (ADY would meet this requirement). | ADY | Analysis Relative Day | Num | Timing | BDS | Cond | |||||||||
| 5 | The level of imputation of analysis date. If ADT (or the date part of ADTM) was imputed, ADTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | ADTF | Analysis Date Imputation Flag | Char | Timing | BDS | Cond | (DATEFL) | ||||||||
| 6 | The level of imputation of analysis time. If ATM (or the time part of ADTM) was imputed, ATMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | ATMF | Analysis Time Imputation Flag | Char | Timing | BDS | Cond | (TIMEFL) | ||||||||
| 7 | The start date associated with AVAL and/or AVALC. ASTDT and AENDT may be useful for traceability when AVAL summarizes data collected over an interval of time, or when AVAL is a duration. | ASTDT | Analysis Start Date | Num | Timing | BDS | Cond | |||||||||
| 8 | The start time associated with AVAL and/or AVALC. ASTTM and AENTM may be useful for traceability when AVAL summarizes data collected over an interval of time, or when AVAL is a duration. | ASTTM | Analysis Start Time | Num | Timing | BDS | Cond | |||||||||
| 9 | The start datetime associated with AVAL and/or AVALC. ASTDTM and AENDTM may be useful for traceability when AVAL summarizes data collected over an interval of time, or when AVAL is a duration. | ASTDTM | Analysis Start Datetime | Num | Timing | BDS | Cond | |||||||||
| 10 | The number of days from an anchor date (not necessarily DM.RFSTDTC) to ASTDT. See Section 3.1.2, Timing Variable Conventions. If a dataset contains more than one record per parameter per subject then, an SDTM or ADaM relative timing variable must be present (ASTDY would meet this requirement). | ASTDY | Analysis Start Relative Day | Num | Timing | BDS | Cond | |||||||||
| 11 | The level of imputation of analysis start date. If ASTDT (or the date part of ASTDTM) was imputed, ASTDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | ASTDTF | Analysis Start Date Imputation Flag | Char | Timing | BDS | Cond | (DATEFL) | ||||||||
| 12 | The level of imputation of analysis start time. If ASTTM (or the time part of ASTDTM) was imputed, ASTTMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | ASTTMF | Analysis Start Time Imputation Flag | Char | Timing | BDS | Cond | (TIMEFL) | ||||||||
| 13 | The end date associated with AVAL and/or AVALC. See also ASTDT. | AENDT | Analysis End Date | Num | Timing | BDS | Cond | |||||||||
| 14 | The end time associated with AVAL and/or AVALC. See also ASTTM. | AENTM | Analysis End Time | Num | Timing | BDS | Cond | |||||||||
| 15 | The end datetime associated with AVAL and/or AVALC. See also ASTDTM. | AENDTM | Analysis End Datetime | Num | Timing | BDS | Cond | |||||||||
| 16 | The number of days from an anchor date (not necessarily DM.RFSTDTC) to AENDT. See Section 3.1.2, Timing Variable Conventions. If a dataset contains more than one record per parameter per subject, then an SDTM or ADaM relative timing variable must be present (AENDY would meet this requirement). | AENDY | Analysis End Relative Day | Num | Timing | BDS | Cond | |||||||||
| 17 | The level of imputation of analysis end date. If AENDT (or the date part of AENDTM) was imputed, AENDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | AENDTF | Analysis End Date Imputation Flag | Char | Timing | BDS | Cond | (DATEFL) | ||||||||
| 18 | The level of imputation of analysis end time. If AENTM (or the time part of AENDTM) was imputed, AENTMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | AENTMF | Analysis End Time Imputation Flag | Char | Timing | BDS | Cond | (TIMEFL) | ||||||||
| 19 | The analysis visit description; required if an analysis is done by nominal, assigned or analysis visit. AVISIT may contain the visit names as observed (i.e., from SDTM VISIT), derived visit names, time window names, conceptual descriptions (such as Average, Endpoint, etc.), or a combination of any of these. AVISIT is a derived field and does not have to map to VISIT from the SDTM. AVISIT represents the analysis visit of the record, but it does not mean that the record was analyzed. There are often multiple records for the same subject and parameter that have the same value of AVISIT. ANLzzFL and other variables may be needed to identify the records selected for any given analysis. See Section 3.3.8, Indicator Variables for BDS Datasets, for information about flag variables. AVISIT should be unique for a given analysis visit window. In the event that a record does not fall within any predefined analysis timepoint window, AVISIT can be populated in any way that the producer chooses to indicate this fact (e.g., blank or "Not Windowed"). The way that AVISIT is calculated, including the variables used in its derivation, should be indicated in the variable metadata for AVISIT. The values and the rules for deriving AVISIT may be different for different parameters within the same dataset. Values of AVISIT are producer-defined, and are often directly usable in Clinical Study Report displays. If a dataset contains more than one record per parameter per subject, then an SDTM or ADaM relative timing variable must be present (AVISIT could meet this requirement). | AVISIT | Analysis Visit | Char | Timing | BDS | Cond | |||||||||
| 20 | Numeric representation of AVISIT. Since study visits are usually defined by certain timepoints, defining AVISITN so that it represents the timepoint associated with the visit can facilitate plotting and interpretation of the values. Alternatively, AVISITN may be a protocol visit number, a cycle number, an analysis visit number, or any other number logically related to AVISIT or useful for sorting that is needed for analysis. \n There must be a one-to-one relationship between AVISITN and AVISIT (i.e., AVISITN has the same value for each distinct AVISIT) within a parameter. A best practice is to extend the one-to-one relationship to within a study, but this is not an ADaM requirement. In the event that a record does not fall within any predefined analysis timepoint window, AVISITN can be populated in any way that the producer chooses to indicate this fact (e.g., may be null). Values of AVISITN are producer-defined. \n AVISITN cannot be present unless AVISIT is also present. On a given record, AVISITN cannot be populated if AVISIT is null. AVISITN can be null when AVISIT is populated, as long as the one-to-one relationship is maintained within a parameter on all rows on which both variables are populated. | AVISITN | Analysis Visit (N) | Num | Timing | BDS | Perm | |||||||||
| 21 | The analysis timepoint description; required if an analysis is done by nominal, assigned or analysis timepoint (instead of or in addition to by-visit). Timepoints are relative to ATPTREF. ATPT may contain the timepoint names as observed (i.e., from SDTM --TPT), derived timepoint names, time window names, conceptual descriptions (such as Average, Endpoint, etc.), or a combination of any of these. This variable is often used in conjunction with AVISIT. ATPT represents the analysis timepoint of the record. \n ATPT can be within an analysis visit (e.g., blood pressure assessments at 10 min, 20 min, and 30 min post-dose at AVISIT=Week 1) or can be unrelated to AVISIT (e.g., migraine symptoms 30 min, 60 min, and 120 min post-dose for attack 1). \n The way that ATPT is calculated, including the variables used in its derivation, should be indicated in the variable metadata for ATPT. The values and the rules for deriving ATPT may be different for different parameters within the same dataset. Values of ATPT are producer-defined, and are often directly usable in Clinical Study Report displays. \n If a dataset contains more than one record per parameter per subject, then an SDTM or ADaM relative timing variable must be present (ATPT could meet this requirement). | ATPT | Analysis Timepoint | Char | Timing | BDS | Cond | |||||||||
| 22 | Numeric representation of ATPT. Defining ATPTN so that its values represent the planned timepoints (e.g., minutes or hours after dosing) is not required but can facilitate plotting and interpretation of the values. There must be a one-to-one relationship between ATPTN and ATPT within a parameter. (Best practice would dictate that the mapping would be one-to-one within a study, but that is not an ADaM requirement.) \n ATPTN cannot be present unless ATPT is also present. When ATPT and ATPTN are present, then on a given record, either both must be populated or both must be null. | ATPTN | Analysis Timepoint (N) | Num | Timing | BDS | Perm | |||||||||
| 23 | Description of the fixed reference point referred to by ATPT/ATPTN (e.g., time of dose). | ATPTREF | Analysis Timepoint Reference | Char | Timing | BDS | Perm | |||||||||
| 24 | APHASE is a categorization of timing within a study, for example a higher-level categorization of APERIOD or an analysis epoch. For example, APHASE could describe spans of time for SCREENING, ON TREATMENT, and FOLLOW-UP. APHASE may be used alone or in addition to APERIOD. APHASE is independent of TRTxxP within ADSL. APHASE may be populated for spans of time where a subject is not on treatment. The value of APHASE (if populated) must be one of the values found in the ADSL APHASEw variables. | APHASE | Phase | Char | Timing | BDS | Perm | |||||||||
| 25 | Numeric representation of APHASE. The value of APHASEN (if populated) must be one of the w values found in the ADSL APHASEw variable names. There must be a one-to-one relationship between APHASEN and APHASE within a study, which must be the same as the one-to-one mapping between w and APHASEw in ADSL. \n APHASEN cannot be present unless APHASE is also present. When APHASE and APHASEN are present, then on a given record, either both must be populated or both must be null. | APHASEN | Phase (N) | Num | Timing | BDS | Perm | |||||||||
| 26 | APERIOD is a record-level timing variable that represents the analysis period within the study associated with the record for analysis purposes. The value of APERIOD (if populated) must be one of the xx values found in the ADSL TRTxxP variable names. APERIOD is required if ASPER is present. APERIOD must be populated on all records where ASPER is populated. \n | APERIOD | Period | Num | Timing | BDS | Cond | |||||||||
| 27 | Text characterizing to which analysis period the record belongs. There must be a one-to-one relationship between APERIODC and APERIOD within a study. \n APERIODC cannot be present unless APERIOD is also present. When APERIOD and APERIODC are present, then on a given record, either both must be populated or both must be null. | APERIODC | Period (C) | Char | Timing | BDS | Perm | |||||||||
| 28 | The numeric value characterizing a sublevel within APERIOD to which the record belongs. Within each APERIOD, the first ASPER is 1 (i.e., it resets to 1 when the APERIOD value changes). The value of ASPER (if populated) must be one of the w values found in the ADSL PxxSw variable names. \n | ASPER | Subperiod within Period | Num | Timing | BDS | Perm | |||||||||
| 29 | Text characterizing to which subperiod the record belongs. There must be a one-to-one relationship between ASPERC and ASPER within a value of APERIOD, which must be the same as the one-to-one mapping between PxxSw and w in ADSL, where xx is equal to the value of APERIOD. The value of ASPERC (if populated) must be one of the values found in the ADSL PxxSw variables. \n ASPERC cannot be present unless ASPER is also present. When ASPER and ASPERC are present, then on a given record, either both must be populated or both must be null. | ASPERC | Subperiod within Period (C) | Char | Timing | BDS | Perm | |||||||||
| 30 | The time relative to an anchor time. The amount of time from an anchor time to ATM. When ARELTM is present, the anchor time variable and ARELTMU must also be included in the dataset, and the anchor time variable must be identified in the metadata for ARELTM. | ARELTM | Analysis Relative Time | Num | Timing | BDS | Perm | |||||||||
| 31 | The units of ARELTM. For example, "HOURS" or "MINUTES." ARELTMU is required if ARELTM is present. | ARELTMU | Analysis Relative Time Unit | Char | Timing | BDS | Perm | |||||||||
| 1 | The starting date for the period defined by APERIOD. | APERSDT | Period Start Date | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 2 | The starting time for the period defined by APERIOD. | APERSTM | Period Start Time | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 3 | The starting datetime for the period defined by APERIOD. | APERSDTM | Period Start Datetime | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 4 | The level of imputation of period start date. If APERSDT (or the date part of APERSDTM) was imputed, APERSDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | APERSDTF | Period Start Date Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (DATEFL) | ||||||||
| 5 | The level of imputation of period start time. If APERSTM (or the time part of APERSDTM) was imputed, APERSTMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | APERSTMF | Period Start Time Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (TIMEFL) | ||||||||
| 6 | The ending date for the period defined by APERIOD. | APEREDT | Period End Date | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 7 | The ending time for the period defined by APERIOD. | APERETM | Period End Time | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 8 | The ending datetime for the period defined by APERIOD. | APEREDTM | Period End Datetime | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 9 | The level of imputation of period end date. If APEREDT (or the date part of APEREDTM) was imputed, APEREDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | APEREDTF | Period End Date Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (DATEFL) | ||||||||
| 10 | The level of imputation of period end time. If APERETM (or the time part of APEREDTM) was imputed, APERETMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | APERETMF | Period End Time Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (TIMEFL) | ||||||||
| 11 | The starting date for the subperiod defined by ASPER. | ASPRSDT | Subperiod Start Date | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 12 | The starting time for the subperiod defined by ASPER. | ASPRSTM | Subperiod Start Time | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 13 | The starting datetime for the subperiod defined by ASPER. | ASPRSDTM | Subperiod Start Datetime | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 14 | The level of imputation of subperiod start date. If ASPRSDT (or the date part of ASPRSDTM) was imputed, ASPRSDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | ASPRSDTF | Subperiod Start Date Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (DATEFL) | ||||||||
| 15 | The level of imputation of subperiod start time. If ASPRSTM (or the time part of ASPRSDTM) was imputed, ASPRSTMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | ASPRSTMF | Subperiod Start Time Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (TIMEFL) | ||||||||
| 16 | The ending date for the subperiod defined by ASPER. | ASPREDT | Subperiod End Date | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 17 | The ending time for the subperiod defined by ASPER. | ASPRETM | Subperiod End Time | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 18 | The ending datetime for the subperiod defined by ASPER. | ASPREDTM | Subperiod End Datetime | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 19 | The level of imputation of subperiod end date. If ASPREDT (or the date part of ASPREDTM) was imputed, ASPREDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | ASPREDTF | Subperiod End Date Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (DATEFL) | ||||||||
| 20 | The level of imputation of subperiod end time. If ASPRETM (or the time part of ASPREDTM) was imputed, ASPRETMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | ASPRETMF | Subperiod End Time Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (TIMEFL) | ||||||||
| 21 | The starting date for the phase defined by APHASE. | PHSDT | Phase Start Date | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 22 | The starting time for the phase defined by APHASE. | PHSTM | Phase Start Time | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 23 | The starting datetime for the phase defined by APHASE. | PHSDTM | Phase Start Datetime | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 24 | The level of imputation of phase start date. If PHSDT (or the date part of PHSDTM) was imputed, PHSDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | PHSDTF | Phase Start Date Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (DATEFL) | ||||||||
| 25 | The level of imputation of phase start time. If PHSTM (or the time part of PHSDTM) was imputed, PHSTMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | PHSTMF | Phase Start Time Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (TIMEFL) | ||||||||
| 26 | The ending date for the phase defined by APHASE. | PHEDT | Phase End Date | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 27 | The ending time for the phase defined by APHASE. | PHETM | Phase End Time | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 28 | The ending datetime for the phase defined by APHASE. | PHEDTM | Phase End Datetime | Num | Period, Subperiod, and Phase Start and End Timing | BDS | Perm | |||||||||
| 29 | The level of imputation of phase end date. If PHEDT (or the date part of PHEDTM) was imputed, PHEDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | PHEDTF | Phase End Date Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (DATEFL) | ||||||||
| 30 | The level of imputation of phase end time. If PHETM (or the time part of PHEDTM) was imputed, PHETMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | PHETMF | Phase End Time Imput. Flag | Char | Period, Subperiod, and Phase Start and End Timing | BDS | Cond | (TIMEFL) | ||||||||
| 1 | Analysis date not directly characterizing AVAL and/or AVALC in numeric format. | *DT | {Date} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 2 | Analysis time not directly characterizing AVAL and/or AVALC in numeric format. | *TM | {Time} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 3 | Analysis datetime not directly characterizing AVAL and/or AVALC in numeric format. | *DTM | {Datetime} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 4 | Analysis relative day not directly characterizing AVAL and/or AVALC. | *ADY | {Relative Day} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 5 | The level of imputation of *DT. If *DT (or the date part of *DTM) was imputed, *DTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | *DTF | {Date Imputation Flag} | Char | Suffixes for User-Defined Timing | BDS | Cond | (DATEFL) | ||||||||
| 6 | The level of imputation of *TM. If *TM (or the time part of *DTM) was imputed, *TMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | *TMF | {Time Imputation Flag} | Char | Suffixes for User-Defined Timing | BDS | Cond | (TIMEFL) | ||||||||
| 7 | Starting analysis date not directly characterizing AVAL and/or AVALC in numeric format. | *SDT | {Start Date} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 8 | Starting analysis time not directly characterizing AVAL and/or AVALC in numeric format. | *STM | {Start Time} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 9 | Starting analysis datetime not directly characterizing AVAL and/or AVALC in numeric format. | *SDTM | {Start Datetime} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 10 | Starting analysis relative day not directly characterizing AVAL and/or AVALC. | *SDY | {Relative Start Day} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 11 | The level of imputation of *SDT. If *SDT (or the date part of *SDTM) was imputed, *SDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | *SDTF | {Start Date Imputation Flag} | Char | Suffixes for User-Defined Timing | BDS | Cond | (DATEFL) | ||||||||
| 12 | The level of imputation of *STM. If *STM (or the time part of *SDTM) was imputed, *STMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | *STMF | {Start Time Imputation Flag} | Char | Suffixes for User-Defined Timing | BDS | Cond | (TIMEFL) | ||||||||
| 13 | Ending analysis date not directly characterizing AVAL and/or AVALC in numeric format. | *EDT | {End Date} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 14 | Ending analysis time not directly characterizing AVAL and/or AVALC in numeric format. | *ETM | {End Time} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 15 | Ending analysis datetime not directly characterizing AVAL and/or AVALC in numeric format. | *EDTM | {End Datetime} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 16 | Ending analysis relative day not directly characterizing AVAL and/or AVALC. | *EDY | {Relative End Day} | Num | Suffixes for User-Defined Timing | BDS | Perm | |||||||||
| 17 | The level of imputation of *EDT. If *EDT (or the date part of *EDTM) was imputed, *EDTF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | *EDTF | {End Date Imputation Flag} | Char | Suffixes for User-Defined Timing | BDS | Cond | (DATEFL) | ||||||||
| 18 | The level of imputation of *ETM. If *ETM (or the time part of *EDTM) was imputed, *ETMF must be populated and is required. See Section 3.1.3, Date and Time Imputation Flag Variables. | *ETMF | {End Time Imputation Flag} | Char | Suffixes for User-Defined Timing | BDS | Cond | (TIMEFL) | ||||||||
| 1 | The description of the analysis parameter. PARAM must include all descriptive and qualifying information relevant to the analysis purpose of the parameter. \n Some examples are: "Supine Systolic Blood Pressure (mm Hg)", "Log10 (Weight (kg))", "Time to First Hypertension Event (Days)", and "Estimated Tumor Growth Rate". PARAM should be sufficient to describe unambiguously the contents of AVAL and/or AVALC. \n Examples of qualifying information that might be relevant to analysis, and are therefore candidates for inclusion in PARAM, are units, specimen type, location, position, machine type, and transformation function. There is no need to include qualifiers that are not relevant to the analysis of PARAM. In contrast to SDTM --TEST, no additional variable is needed to further qualify PARAM. \n PARAM is restricted to a maximum of 200 characters. If the value of PARAM will be used as a variable label in a transposed dataset, then the producer may wish to limit the value of PARAM to 40 characters. Such limitation to 40 characters should not compromise the integrity of the description. \n PARAM is often directly usable in Clinical Study Report displays. Note that in the ADaMIG, "parameter" is a synonym of "analysis parameter." \n PARAM must be present and populated on every record in a BDS dataset. | PARAM | Parameter | Char | Analysis Parameter | BDS | Req | |||||||||
| 2 | The short name of the analysis parameter in PARAM. The values of PARAMCD must be no more than 8 characters in length, start with a letter (not underscore), and be comprised only of letters (A-Z), underscore (_), and numerals (0-9). These constraints will allow for a BDS dataset to be transposed in such a way that the values of PARAMCD can be used as valid ADaM variable names per Section 3.1.1, General Variable Conventions. There must be a one-to-one relationship between PARAM and PARAMCD within a dataset. \n PARAMCD must be present and populated on every record in a BDS dataset. | PARAMCD | Parameter Code | Char | Analysis Parameter | BDS | Req | |||||||||
| 3 | Numeric representation of PARAM. Useful for ordering and programmatic manipulation. There must be a one-to-one relationship between PARAM and PARAMN within a dataset for all parameters where PARAMN is populated. \n if PARAMN is populated on any record for a PARAM, it must be populated on every record for that PARAM. | PARAMN | Parameter (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 4 | A categorization of PARAM within a dataset. For example, values of PARCAT1 might group the parameters having to do with a particular questionnaire, lab specimen type, or area of investigation. Note that PARCATy is not a qualifier for PARAM. PARAM to PARCATy is a many-to-one mapping; any given PARAM may be associated with at most one level of PARCATy (e.g., one level of PARCAT1 and one level of PARCAT2). | PARCATy | Parameter Category y | Char | Analysis Parameter | BDS | Perm | |||||||||
| 5 | Numeric representation of PARCATy. Useful for the ordering of values of PARCATy or for other purposes. There must be a one-to-one relationship between PARCATy and PARCATyN within a dataset. \n PARCATyN cannot be present unless PARCATy is also present. When PARCATy and PARCATyN are present, then on a given record, either both must be populated or both must be null. | PARCATyN | Parameter Category y (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 6 | Numeric analysis value described by PARAM. On a given record, it is permissible for AVAL, AVALC, or both to be null. AVAL is required if AVALC is not present, since either AVAL or AVALC must be present in the dataset. | AVAL | Analysis Value | Num | Analysis Parameter | BDS | Cond | |||||||||
| 7 | Character analysis value described by PARAM. AVALC can be a character string mapping to AVAL, but if so there must be a one-to-one relationship between AVAL and AVALC within a given PARAM. AVALC should not be used to categorize the values of AVAL. Within a given parameter, if there exists a row on which both AVALC and AVAL are populated, then there must be a one-to-one relationship between AVALC and AVAL on all rows on which both variables are populated. (In other words, there is no requirement that records with a null value in either AVAL or AVALC be included when determining whether the one-to-one relationship requirement is satisfied.) On a given record, it is permissible for AVAL, AVALC, or both to be null. \n AVALC is required if AVAL is not present, since either AVAL or AVALC must be present in the dataset. | AVALC | Analysis Value (C) | Char | Analysis Parameter | BDS | Cond | |||||||||
| 8 | A categorization of AVAL or AVALC within a parameter. Not necessarily a one-to-one mapping to AVAL and/or AVALC. For example, if PARAM is "Headache Severity" and AVAL has values 0, 1, 2, or 3, AVALCAT1 can categorize AVAL into "None or Mild" (for AVAL 0 or 1) and "Moderate or Severe" (for AVAL 2 or 3). AVALCATy is parameter variant. | AVALCATy | Analysis Value Category y | Char | Analysis Parameter | BDS | Perm | |||||||||
| 9 | Numeric representation of AVALCATy. Useful for ordering of values of AVALCATy or for other purposes. There must be a one-to-one relationship between AVALCAyN and AVALCATy within a parameter. \n AVALCAyN cannot be present unless AVALCATy is also present. When AVALCATy and AVALCAyN are present, then on a given record, either both must be populated or both must be null. | AVALCAyN | Analysis Value Category y (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 10 | The subject's baseline analysis value for a parameter and baseline definition (i.e., BASETYPE) if present. BASE contains the value of AVAL copied from a record within the parameter on which ABLFL = "Y". Required if dataset supports analysis or review of numeric baseline value or functions of numeric baseline value. If BASE is populated for a parameter, and BASE is non-null for a subject for that parameter, then there must be a record flagged by ABLFL for that subject and parameter. Note that a baseline record may be derived (e.g., it may be an average) in which case DTYPE must be populated on the baseline record. | BASE | Baseline Value | Num | Analysis Parameter | BDS | Cond | |||||||||
| 11 | The subject's baseline value of AVALC for a parameter and baseline definition (i.e., BASETYPE) if present. May be needed when AVALC is of interest. BASEC contains the value of AVALC copied from a record within the parameter on which ABLFL = "Y". If both AVAL and AVALC are populated within a parameter, the baseline record for AVALC must be the same record as that for AVAL. \n Within a given parameter, if there exists a row on which both BASEC and BASE are populated, then there must be a one-to-one relationship between BASEC and BASE on all rows on which both variables are populated. (In other words, there is no requirement that records with a null value in either BASE or BASEC be included when determining whether the one-to-one relationship requirement is satisfied.) On a given record, it is permissible for BASE, BASEC, or both to be null. | BASEC | Baseline Value (C) | Char | Analysis Parameter | BDS | Perm | |||||||||
| 12 | A categorization of BASE or BASEC within a parameter. Not necessarily a one-to-one mapping to BASE or BASEC. For example, if PARAM is "Headache Severity" and AVAL has values 0, 1, 2, or 3, BASECAT1 can categorize BASE into "None or Mild" (for BASE 0 or 1) and "Moderate or Severe" (for BASE 2 or 3). | BASECATy | Baseline Category y | Char | Analysis Parameter | BDS | Perm | |||||||||
| 13 | Numeric representation of BASECATy. Useful for ordering of values of BASECATy or for other purposes. There must be a one-to-one relationship between BASECAyN and BASECATy within a parameter. \n BASECAyN cannot be present unless BASECATy is also present. When BASECATy and BASECAyN are present, then on a given record, either both must be populated or both must be null. | BASECAyN | Baseline Category y (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 14 | Producer-defined text describing the definition of baseline relevant to the value of BASE on the current record. Required when there are multiple ways that baseline is defined. If used for any PARAM within a dataset, it must be non-null for all records for that PARAM within that dataset where either BASE or BASEC are also non-null. Refer to Section 4.2.1.6, Rule 6, for an example. | BASETYPE | Baseline Type | Char | Analysis Parameter | BDS | Cond | |||||||||
| 15 | Change from baseline analysis value. Equal to AVAL-BASE. If used for a given PARAM, should be populated for all post-baseline records of that PARAM regardless of whether that record is used for analysis. The decision on how to populate pre-baseline and baseline values of CHG is left to producer choice. | CHG | Change from Baseline | Num | Analysis Parameter | BDS | Perm | |||||||||
| 16 | A categorization of CHG within a parameter. Not necessarily a one-to-one mapping to CHG. The definition of CHGCATy may vary by PARAM. For example, CHGCAT1 may be used to categorize CHG with respect to ranges of change in SYSBP; "-10 to -5 mm Hg", "-5 to 0 mm Hg" categories. | CHGCATy | Change from Baseline Category y | Char | Analysis Parameter | BDS | Perm | |||||||||
| 17 | Numeric representation of CHGCATy. Useful for ordering of values of CHGCATy or for other purposes. There must be a one-to-one relationship between CHGCATyN and CHGCATy within a parameter. \n CHGCATyN cannot be present unless CHGCATy is also present. When CHGCATy and CHGCATyN are present, then on a given record, either both must be populated or both must be null. | CHGCATyN | Change from Baseline Category y (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 18 | Percent change from baseline analysis value. Equal to ((AVAL-BASE)/BASE)*100. If used for a given PARAM, should be populated (when calculable) for all post-baseline records of that PARAM regardless of whether that record is used for analysis. The decision on how to populate pre-baseline and baseline values of PCHG is left to producer choice. | PCHG | Percent Change from Baseline | Num | Analysis Parameter | BDS | Perm | |||||||||
| 19 | A categorization of PCHG within a parameter. Not necessarily a one-to-one mapping to PCHG. The definition of PCHGCATy may vary by PARAM. For example, PCHGCAT1 may be used to categorize PCHG with respect to ranges of change in SYSBP; ">5%", ">10%" categories. | PCHGCATy | Percent Chg from Baseline Category y | Char | Analysis Parameter | BDS | Perm | |||||||||
| 20 | Numeric representation of PCHGCATy. Useful for ordering of values of PCHGCATy or for other purposes. There must be a one-to-one relationship between PCHGCAyN and PCHGCATy within a parameter. \n PCHGCAyN cannot be present unless PCHGCATy is also present. When PCHGCATy and PCHGCAyN are present, then on a given record, either both must be populated or both must be null. | PCHGCAyN | Percent Chg from Baseline Category y (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 21 | Ratio to the baseline value. Equal to AVAL / BASE. If used for a given PARAM, should be populated for all post-baseline records of that PARAM regardless of whether that record is used for analysis. The decision on how to populate pre-baseline and baseline values of R2BASE is left to producer choice. | R2BASE | Ratio to Baseline | Num | Analysis Parameter | BDS | Perm | |||||||||
| 22 | Ratio to the lower limit of the analysis range y. Equal to AVAL / AyLO. AyLO must exist in the ADaM dataset. If used for a given PARAM, should be populated for all post-baseline records of that PARAM regardless of whether that record is used for analysis. The decision on how to populate pre-baseline and baseline values of R2AyLO is left to producer choice. | R2AyLO | Ratio to Analysis Range y Lower Limit | Num | Analysis Parameter | BDS | Perm | |||||||||
| 23 | Ratio to the upper limit of the analysis range y. Equal to AVAL / AyHI. AyHI must exist in the ADaM dataset. If used for a given PARAM, should be populated for all post-baseline records of that PARAM regardless of whether that record is used for analysis. The decision on how to populate pre-baseline and baseline values of R2AyHI is left to producer choice. | R2AyHI | Ratio to Analysis Range y Upper Limit | Num | Analysis Parameter | BDS | Perm | |||||||||
| 24 | A shift in values depending on the defined pairing for group y within a parameter. SHIFTy can only be based on the change in value of any of the following pairs (BASECATy, AVALCATy), (BNRIND, ANRIND), (ByIND, AyIND), (BTOXGR, ATOXGR), (BTOXGRL, ATOXGRL), (BTOXGRH, ATOXGRH), (BASE, AVAL) or (BASEC, AVALC). Useful for shift tables. For example, "NORMAL to HIGH". If used for a given PARAM, should be populated (when calculable) for all post-baseline records of that PARAM regardless of whether that record is used for analysis. The decision on how to populate baseline and pre-baseline values of SHIFTy is left to producer choice. | SHIFTy | Shift y | Char | Analysis Parameter | BDS | Perm | |||||||||
| 25 | Numeric representation of SHIFTy. There must be a one-to-one relationship between SHIFTyN and SHIFTy within a parameter.SHIFTyN cannot be present unless SHIFTy is also present. When SHIFTy and SHIFTyN are present, then on a given record, either both must be populated or both must be null.If SHIFTyN is used for a given PARAM, SHIFTy and SHIFTyN should be populated (when calculable) for all post-baseline records of that PARAM regardless of whether that record is used for analysis. | SHIFTyN | Shift y (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 26 | Change to baseline analysis value. Equal to BASE-AVAL. If used for a given PARAM, should be populated for all post-baseline records of that PARAM regardless of whether that record is used for analysis. The decision on how to populate pre-baseline and baseline values of BCHG is left to producer choice. | BCHG | Change to Baseline | Num | Analysis Parameter | BDS | Perm | |||||||||
| 27 | A categorization of BCHG within a parameter. Not necessarily a one-to-one mapping to BCHG. The definition of BCHGCATy may vary by PARAM. For example, BCHGCAT1 may be used to categorize BCHG with respect to ranges of change in SYSBP; "-10 to -5 mm Hg", "-5 to 0 mm Hg" categories. | BCHGCATy | Change to Baseline Category y | Char | Analysis Parameter | BDS | Perm | |||||||||
| 28 | Numeric representation of BCHGCATy. Useful for ordering of values of BCHGCATy or for other purposes. There must be a one-to-one relationship between BCHGCAyN and BCHGCATy within a parameter. \n BCHGCAyN cannot be present unless BCHGCATy is also present. When BCHGCATy and BCHGCAyN are present, then on a given record, either both must be populated or both must be null. | BCHGCAyN | Change to Baseline Category y (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 29 | Percent change to baseline analysis value. Equal to ((BASE-AVAL)/AVAL)*100. If used for a given PARAM, should be populated (when calculable) for all post-baseline records of that PARAM regardless of whether that record is used for analysis. The decision on how to populate pre-baseline and baseline values of PBCHG is left to producer choice | PBCHG | Percent Change to Baseline | Num | Analysis Parameter | BDS | Perm | |||||||||
| 30 | A categorization of PBCHG within a parameter. Not necessarily a one-to-one mapping to PBCHG. The definition of PBCHGCAy may vary by PARAM. For example, PBCHGCA1 may be used to categorize PBCHG with respect to ranges of change in SYSBP; ">5%", ">10%" categories. | PBCHGCAy | Percent Change to Baseline Category y | Char | Analysis Parameter | BDS | Perm | |||||||||
| 31 | Numeric representation of PBCHGCAy. Useful for ordering of values of PBCHGCAy or for other purposes. There must be a one-to-one relationship between PBCHGCyN and PBCHGCAy within a parameter. \n PBCHGCyN cannot be present unless PBCHGCAy is also present. When PBCHGCAy and PBCHGCyN are present, then on a given record, either both must be populated or both must be null. | PBCHGCyN | Percent Change to Baseline Category y (N) | Num | Analysis Parameter | BDS | Perm | |||||||||
| 1 | A text string identifying a pre-specified criterion within a parameter, for example SYSBP > 90. Required if CRITyFL is present. In some cases, the presence of the text string indicates that the criterion is satisfied on this record and CRITyFL is set to Y, while a null value indicates that the criterion is not satisfied or is not evaluable and is accompanied by a null value in CRITyFL. In other cases, the text string identifies the criterion being evaluated and is populated on every row for the parameter, but whether or not the criterion is satisfied is indicated by the value of the variable CRITyFL. See CRITyFL and CRITyFN. \n Refer to Section 4.7, Identification of Records which Satisfy a Predefined Criterion for Analysis Purposes, for additional discussion of CRITy, CRITyFL and CRITyFN. | CRITy | Analysis Criterion y | Char | Analysis Parameter Criteria | BDS | Perm | |||||||||
| 2 | Character flag variable indicating whether the criterion defined in CRITy was met by the data on the record. See CRITy for more information regarding how to use CRITy and CRITyFL to indicate whether a criterion is met. Required if CRITy is present. \n Refer to Section 4.7, Identification of Records which Satisfy a Predefined Criterion for Analysis Purposes, for additional discussion. | CRITyFL | Criterion y Evaluation Result Flag | Char | Analysis Parameter Criteria | BDS | Cond | Y or Y, N | ||||||||
| 3 | Numeric representation of CRITyFL. There must be a one-to-one relationship between CRITyFN and CRITyFL within a parameter. \n CRITyFN cannot be present unless CRITyFL is also present. When CRITyFL and CRITyFN are present, then on a given record, either both must be populated or both must be null. | CRITyFN | Criterion y Evaluation Result Flag (N) | Num | Analysis Parameter Criteria | BDS | Perm | 1 or 1, 0 | ||||||||
| 4 | A text string identifying a pre-specified criterion within a parameter, where the criterion can have multiple responses (as opposed to CRITy which has binary responses). Required if MCRITyML is present. For example, the grade of a lab analyte is compared to the baseline grade, with the possible conditions being 0 to 1, 0 to 2, etc. The text string identifies the criterion being evaluated (for example, "Grade increase") and is populated on every row for the parameter; which level of the criterion is satisfied is indicated by the value of the variable MCRITyML (for example "0 to 1", "0 to 2", etc.). \n See MCRITyML and MCRITyMN below, and refer to Section 4.7, Identification of Records which Satisfy a Predefined Criterion for Analysis Purposes, for additional discussion of MCRITy, MCRITyML, and MCRITyMN. | MCRITy | Analysis Multi-Response Criterion y | Char | Analysis Parameter Criteria | BDS | Perm | |||||||||
| 5 | Character variable indicating which level of the criterion defined in MCRITy was met by the data on the record. See MCRITy for more information regarding how to use MCRITy and MCRITyML to indicate whether a criterion was met. Content is sponsor-defined. Required if MCRITy is present. | MCRITyML | Multi-Response Criterion y Evaluation | Char | Analysis Parameter Criteria | BDS | Cond | |||||||||
| 6 | Numeric representation of MCRITyML. There must be a one-to-one relationship between MCRITyMN and MCRITyML within a parameter. Content is sponsor-defined. \n MCRITyMN cannot be present unless MCRITyML is also present. When MCRITyML and MCRITyMN are present, then on a given record, either both must be populated or both must be null. | MCRITyMN | Multi-Response Criterion y Eval (N) | Num | Analysis Parameter Criteria | BDS | Perm | |||||||||
| 1 | Analysis value derivation method. DTYPE is used to denote, and must be populated, when the value of AVAL or AVALC has been imputed or derived differently than the other analysis values within the parameter. DTYPE is required to be populated even if AVAL and AVALC are null on the derived record. \n Three common situations when DTYPE should be populated: \n * A new row is added within a parameter with the analysis value populated based on other rows within the parameter. \n * A new row is added within a parameter with the analysis value populated based on a constant value or data from other subjects. \n * An analysis value (AVAL or AVALC) on an existing record is being replaced with a value based on a pre-specified algorithm. \n DTYPE is used to denote analysis values that are "special cases" within a parameter. For each value of DTYPE, the precise derivation algorithm must be defined in analysis variable metadata, even for DTYPE values in the CDISC Controlled Terminology. The controlled terminology for DTYPE is extensible. See Section 4, Implementation Issues, Standard Solutions, and Examples for examples of the use of DTYPE. \n Some examples of DTYPE values:LOCF = last observation carried forwardWOCF = worst observation carried forwardAVERAGE = average of values | DTYPE | Derivation Type | Char | Analysis Descriptor | BDS | Cond | (DTYPE) | ||||||||
| 1 | The range of values that are valid for a given analysis timepoint (a given value of AVISIT). For example, "5-9 DAYS". | AWRANGE | Analysis Window Valid Relative Range | Char | Analysis Visit Windowing | BDS | Perm | |||||||||
| 2 | The target or most desired analysis relative day (ADY) value or analysis relative time (ARELTM) value for a given value of AVISIT. | AWTARGET | Analysis Window Target | Num | Analysis Visit Windowing | BDS | Perm | |||||||||
| 3 | Absolute difference between ADY or ARELTM and AWTARGET. It will be necessary to adjust for the fact that there is no Day 0 in the event that ADY and AWTARGET are not of the same sign. \n If the sign of the difference is important, then AWTDIFF might have to be used in conjunction with ADY or ARELTM and possibly AWTARGET when choosing among records. | AWTDIFF | Analysis Window Diff from Target | Num | Analysis Visit Windowing | BDS | Perm | |||||||||
| 4 | The value of the beginning timepoint (inclusive) needs to be used in conjunction to AWRANGE. For example, if AWRANGE is "5-9 DAYS", then AWLO is "5". | AWLO | Analysis Window Beginning Timepoint | Num | Analysis Visit Windowing | BDS | Perm | |||||||||
| 5 | The value of the ending timepoint (inclusive) needs to be used in conjunction to AWRANGE. For example, if AWRANGE is "5-9 DAYS", then AWHI is "9". | AWHI | Analysis Window Ending Timepoint | Num | Analysis Visit Windowing | BDS | Perm | |||||||||
| 6 | Unit used for AWTARGET, AWTDIFF, AWLO and AWHI. Examples: DAYS, HOURS. | AWU | Analysis Window Unit | Char | Analysis Visit Windowing | BDS | Perm | |||||||||
| 1 | The original date of risk for the time-to-event analysis. This is generally the point at which a subject is first at risk for the event of interest evaluation (as defined in the Protocol or SAP). For example, this may be the randomization date or the date of first study therapy exposure. | STARTDT | Time-to-Event Origin Date for Subject | Num | Time-to-Event | BDS | Perm | |||||||||
| 2 | The original datetime of risk for the time-to-event analysis. This is generally the point at which a subject is first at risk for the event of interest evaluation (as defined in the Protocol or SAP). For example, this may be the randomization datetime or the datetime of first study therapy exposure. | STARTDTM | Time-to-Event Origin Datetime | Num | Time-to-Event | BDS | Perm | |||||||||
| 3 | The level of imputation of the start date. See Section 3.1.3, Date and Time Imputation Flag Variables. | STARTDTF | Origin Date Imputation Flag | Char | Time-to-Event | BDS | Cond | (DATEFL) | ||||||||
| 4 | The level of imputation of the start time. See Section 3.1.3, Date and Time Imputation Flag Variables. | STARTTMF | Origin Time Imputation Flag | Char | Time-to-Event | BDS | Cond | (TIMEFL) | ||||||||
| 5 | Defines whether the event was censored for the subject within the parameter (period of observation truncated prior to event being observed). It is strongly recommended to use 0 as an event indicator and positive integers as censoring indicators. It is also recommended that unique positive integers be used to indicate coded descriptions of censoring reasons. CNSR is required for time-to-event parameters. | CNSR | Censor | Num | Time-to-Event | BDS | Cond | |||||||||
| 6 | Description of the event of interest or censoring reason for the subject within the parameter. | EVNTDESC | Event or Censoring Description | Char | Time-to-Event | BDS | Perm | |||||||||
| 7 | Describes the circumstance represented by the censoring date if different from the event date that warrants censoring. | CNSDTDSC | Censor Date Description | Char | Time-to-Event | BDS | Perm | |||||||||
| 1 | Toxicity grade of AVAL or AVALC for analysis; may be based on SDTM --TOXGR or an imputed or assigned value. | ATOXGR | Analysis Toxicity Grade | Char | Toxicity and Range | BDS | Perm | |||||||||
| 2 | Numeric representation of ATOXGR. There must be a one-to-one relationship between ATOXGRN and ATOXGR within a parameter. \n ATOXGRN cannot be present unless ATOXGR is also present. When ATOXGR and ATOXGRN are present, then on a given record, either both must be populated or both must be null. | ATOXGRN | Analysis Toxicity Grade (N) | Num | Toxicity and Range | BDS | Perm | |||||||||
| 3 | ATOXGR of the baseline record identified by ABLFL. | BTOXGR | Baseline Toxicity Grade | Char | Toxicity and Range | BDS | Perm | |||||||||
| 4 | Numeric representation of BTOXGR. There must be a one-to-one relationship between BTOXGRN and BTOXGR within a parameter. \n BTOXGRN cannot be present unless BTOXGR is also present. When BTOXGR and BTOXGRN are present, then on a given record, either both must be populated or both must be null. | BTOXGRN | Baseline Toxicity Grade (N) | Num | Toxicity and Range | BDS | Perm | |||||||||
| 5 | Indicates where AVAL or AVALC falls with respect to the normal reference range for analysis; may be based on SDTM --NRIND or an imputed or assigned value. | ANRIND | Analysis Reference Range Indicator | Char | Toxicity and Range | BDS | Perm | |||||||||
| 6 | ANRIND of the baseline record identified by ABLFL. | BNRIND | Baseline Reference Range Indicator | Char | Toxicity and Range | BDS | Perm | |||||||||
| 7 | Normal range lower limit for analysis; may be based on SDTM --NRLO or an imputed or assigned value. | ANRLO | Analysis Normal Range Lower Limit | Num | Toxicity and Range | BDS | Perm | |||||||||
| 8 | Character analysis normal range lower limit. \n ANRLOC can be a character string mapping to ANRLO, but if so there must be a one-to-one relationship between ANRLO and ANRLOC within a given PARAM. ANRLOC should not be used to categorize the values of ANRLO. \n Within a given parameter, if there exists a row on which both ANRLOC and ANRLO are populated, then there must be a one-to-one relationship between ANRLOC and ANRLO on all rows on which both variables are populated. (In other words, there is no requirement that records with a null value in either ANRLO or ANRLOC be included when determining whether the one-to-one relationship requirement is satisfied.) On a given record, it is permissible for ANRLO, ANRLOC, or both to be null. | ANRLOC | Analysis Normal Range Lower Limit (C) | Char | Toxicity and Range | BDS | Perm | |||||||||
| 9 | Normal range upper limit for analysis; may be based on SDTM --NRHI or an imputed or assigned value. | ANRHI | Analysis Normal Range Upper Limit | Num | Toxicity and Range | BDS | Perm | |||||||||
| 10 | Character analysis normal range upper limit. \n ANRHIC can be a character string mapping to ANRHI, but if so there must be a one-to-one relationship between ANRHI and ANRHIC within a given PARAM. ANRHIC should not be used to categorize the values of ANRHI. \n Within a given parameter, if there exists a row on which both ANRHIC and ANRHI are populated, then there must be a one-to-one relationship between ANRHIC and ANRHI on all rows on which both variables are populated. (In other words, there is no requirement that records with a null value in either ANRHI or ANRHIC be included when determining whether the one-to-one relationship requirement is satisfied.) On a given record, it is permissible for ANRHI, ANRHIC, or both to be null. | ANRHIC | Analysis Normal Range Upper Limit (C) | Char | Toxicity and Range | BDS | Perm | |||||||||
| 11 | AyLO and/or AyHI are used for analysis ranges other than the normal range. AyLO and/or AyHI are created to capture the different levels of cutoff values used to determine whether an analysis is within a clinically acceptable value range or outside that value range. AyLO and/or AyHI are usually but not necessarily constants, parameter-specific constants, or subject-specific constants. AyLO must be included if R2AyLO is included in the dataset. | AyLO | Analysis Range y Lower Limit | Num | Toxicity and Range | BDS | Cond | |||||||||
| 12 | Character analysis range y lower limit. \n AyLOC can be a character string mapping to AyLO, but if so there must be a one-to-one relationship between AyLO and AyLOC within a given PARAM. AyLOC should not be used to categorize the values of AyLO. \n Within a given parameter, if there exists a row on which both AyLOC and AyLO are populated, then there must be a one-to-one relationship between AyLOC and AyLO on all rows on which both variables are populated. (In other words, there is no requirement that records with a null value in either AyLO or AyLOC be included when determining whether the one-to-one relationship requirement is satisfied.) On a given record, it is permissible for AyLO, AyLOC, or both to be null. | AyLOC | Analysis Range y Lower Limit (C) | Char | Toxicity and Range | BDS | Perm | |||||||||
| 13 | See AyLO. \n For example, if ECG QTc values are summarized based on values >450, values >480, and values >500, there is a need for 3 "hi value" range variables against which to compare values: A1HI=450, A2HI=480, A3HI=500. \n AyHI must be included if R2AyHI is included in the dataset. | AyHI | Analysis Range y Upper Limit | Num | Toxicity and Range | BDS | Cond | |||||||||
| 14 | Character analysis range y upper limit. \n AyHIC can be a character string mapping to AyHI, but if so there must be a one-to-one relationship between AyHI and AyHIC within a given PARAM. AyHIC should not be used to categorize the values of AyHI. \n Within a given parameter, if there exists a row on which both AyHIC and AyHI are populated, then there must be a one-to-one relationship between AyHIC and AyHI on all rows on which both variables are populated. (In other words, there is no requirement that records with a null value in either AyHI or AyHIC be included when determining whether the one-to-one relationship requirement is satisfied.) On a given record, it is permissible for AyHI, AyHIC, or both to be null. | AyHIC | Analysis Range y Upper Limit (C) | Char | Toxicity and Range | BDS | Perm | |||||||||
| 15 | Indicates relationship of AVAL to the analysis range variables AyLO and/or AyHI, or the relationship of AVALC to the analysis range variables AyLOC and/or AyHIC. | AyIND | Analysis Range y Indicator | Char | Toxicity and Range | BDS | Perm | |||||||||
| 16 | AyIND of the baseline record identified by ABLFL. | ByIND | Baseline Analysis Range y Indicator | Char | Toxicity and Range | BDS | Perm | |||||||||
| 17 | Low toxicity grade of AVAL or AVALC for analysis; may be based on SDTM --TOXGR or an imputed or assigned value. Used to assess when a subject's lab value falls within the low toxicity range. | ATOXGRL | Analysis Toxicity Grade Low | Char | Toxicity and Range | BDS | Perm | |||||||||
| 18 | Numeric representation of ATOXGRL. There must be a one-to-one relationship between ATOXGRLN and ATOXGRL within a parameter. \n ATOXGRLN cannot be present unless ATOXGRL is also present. When ATOXGRL and ATOXGRLN are present, then on a given record, either both must be populated or both must be null. | ATOXGRLN | Analysis Toxicity Grade Low (N) | Num | Toxicity and Range | BDS | Perm | |||||||||
| 19 | High toxicity grade of AVAL or AVALC for analysis; may be based on SDTM --TOXGR or an imputed or assigned value. Used to assess when a subject's lab value falls within the high toxicity range. | ATOXGRH | Analysis Toxicity Grade High | Char | Toxicity and Range | BDS | Perm | |||||||||
| 20 | Numeric representation of ATOXGRH. There must be a one-to-one relationship between ATOXGRHN and ATOXGRH within a parameter. \n ATOXGRHN cannot be present unless ATOXGRH is also present. When ATOXGRH and ATOXGRHN are present, then on a given record, either both must be populated or both must be null. | ATOXGRHN | Analysis Toxicity Grade High (N) | Num | Toxicity and Range | BDS | Perm | |||||||||
| 21 | ATOXGRL of the baseline record identified by ABLFL. | BTOXGRL | Baseline Toxicity Grade Low | Char | Toxicity and Range | BDS | Perm | |||||||||
| 22 | Numeric representation of BTOXGRL. There must be a one-to-one relationship between BTOXGRLN and BTOXGRL within a parameter. \n BTOXGRLN cannot be present unless BTOXGRL is also present. When BTOXGRL and BTOXGRLN are present, then on a given record, either both must be populated or both must be null. | BTOXGRLN | Baseline Toxicity Grade Low (N) | Num | Toxicity and Range | BDS | Perm | |||||||||
| 23 | ATOXGRH of the baseline record identified by ABLFL. | BTOXGRH | Baseline Toxicity Grade High | Char | Toxicity and Range | BDS | Perm | |||||||||
| 24 | Numeric representation of BTOXGRH. There must be a one-to-one relationship between BTOXGRHN and BTOXGRH within a parameter. \n BTOXGRHN cannot be present unless BTOXGRH is also present. When BTOXGRH and BTOXGRHN are present, then on a given record, either both must be populated or both must be null. | BTOXGRHN | Baseline Toxicity Grade High (N) | Num | Toxicity and Range | BDS | Perm | |||||||||
| 25 | The analysis toxicity term used to describe toxicity in the low direction. ATOXDSCL is only populated if AVAL is populated and the PARAM is evaluated for toxicity in the low direction. There is a one-to-one relationship between ATOXDSCL and PARAM within a subject. The intent of this variable is to describe the type of toxicity being evaluated and not the level of toxicity on the specific record. | ATOXDSCL | Analysis Toxicity Description Low | Char | Toxicity and Range | BDS | Perm | |||||||||
| 26 | The analysis toxicity term used to describe toxicity in the high direction. ATOXDSCH is only populated if AVAL is populated and the PARAM is evaluated for toxicity in the high direction. There is a one-to-one relationship between ATOXDSCH and PARAM within a subject. The intent of this variable is to describe the type of toxicity being evaluated and not the level of toxicity on the specific record. | ATOXDSCH | Analysis Toxicity Description High | Char | Toxicity and Range | BDS | Perm | |||||||||
| 1 | Character indicator to identify the baseline record for each subject, parameter, and baseline type (BASETYPE) combination. See BASETYPE in Table 3.3.4.1.1. ABLFL is required if BASE is present in the dataset. \n A baseline record may be derived (e.g., it may be an average), in which case DTYPE must also be populated. If BASE is populated for a parameter, and BASE is non-null for a subject for that parameter, then there must be a record flagged by ABLFL for that subject and parameter. | ABLFL | Baseline Record Flag | Char | Flag | BDS | Cond | Y | ||||||||
| 2 | Numeric representation of ABLFL. There must be a one-to-one relationship between ABLFN and ABLFL. \n ABLFN cannot be present unless ABLFL is also present. When ABLFL and ABLFN are present, then on a given record, either both must be populated or both must be null. | ABLFN | Baseline Record Flag (N) | Num | Flag | BDS | Perm | 1 | ||||||||
| 3 | ANLzzFL is a conditionally required flag to be used in addition to other selection variables when the other selection variables in combination are insufficient to identify the exact set of records used for one or more analyses. Often one ANLzzFL will serve to support the accurate selection of records for more than one analysis. Note that it is allowable to add additional descriptive text to the label (see Section 3.1.6, Additional Information about Section 3, Item 1). \n When defining the set of records used in a particular analysis or family of analyses, ANLzzFL is supplemental to, and is intended to be used in conjunction with, other selection variables, such as subject-level, parameter-level and record-level population flags, AVISIT, DTYPE, grouping variables such as SITEGRy, and others. The lower-case letter "zz" in the variable name is an index for the zzth record selection algorithm where "zz" is replaced with a zero-padded two-digit integer [01-99]. Every record selection algorithm "zz" (i.e., every algorithm for populating an ANLzzFL) must be defined in variable metadata. When the set of records that the algorithm "zz" operates on is pre-filtered by application of other criteria, such as a record-level population flag, then the selection algorithm definition in the metadata must so specify. \n Note that the ANLzzFL value of Y indicates that the record fulfilled the requirements of the algorithm, but does not necessarily imply that the record was actually used in one or more analyses, as whether or not a record is used also depends on the other selection variables applied. The ANLzzFL flag is useful in many circumstances; an example is when there is more than one record for an analysis timepoint within a subject and parameter, as it can be used to identify the record chosen to represent the timepoint for an analysis. "zz" is an index for a record selection algorithm, such as "record closest to target relative day for the AVISIT, with ties broken by the latest record, for each AVISIT within <list of AVISITS>." \n Note that it is not required that a specific ANLzzFL variable has the same definition across a project or even across datasets within a study. There is also no requirement that the ANLzzFL variables in a dataset or study be used in numerical order; e.g. ANL02FL might occur in a dataset or study without ANL01FL present in the same dataset or study. | ANLzzFL | Analysis Flag zz | Char | Flag | BDS | Cond | Y | ||||||||
| 4 | Numeric representation of ANLzzFL. There must be a one-to-one relationship between ANLzzFN and ANLzzFL within a dataset. \n ANLzzFN cannot be present unless ANLzzFL is also present. When ANLzzFL and ANLzzFN are present, then on a given record, either both must be populated or both must be null. | ANLzzFN | Analysis Flag zz (N) | Num | Flag | BDS | Perm | 1 | ||||||||
| 5 | Character indicator of whether the observation occurred while the subject was on treatment. ONTRTFL is producer-defined, and its definition may vary across datasets in a study based on analysis needs. | ONTRTFL | On Treatment Record Flag | Char | Flag | BDS | Perm | Y | ||||||||
| 6 | Numeric representation of ONTRTFL. There must be a one-to-one relationship between ONTRTFN and ONTRTFL within a dataset. \n ONTRTFN cannot be present unless ONTRTFL is also present. When ONTRTFL and ONTRTFN are present, then on a given record, either both must be populated or both must be null. | ONTRTFN | On Treatment Record Flag (N) | Num | Flag | BDS | Perm | 1 | ||||||||
| 7 | Character indicator of the subject's last non-missing value on treatment for each parameter. | LVOTFL | Last Value On Treatment Record Flag | Char | Flag | BDS | Perm | Y | ||||||||
| 8 | Numeric representation of LVOTFL. There must be a one-to-one relationship between LVOTFN and LVOTFL within a dataset. \n LVOTFN cannot be present unless LVOTFL is also present. When LVOTFL and LVOTFN are present, then on a given record, either both must be populated or both must be null. | LVOTFN | Last Value On Treatment Record Flag (N) | Num | Flag | BDS | Perm | 1 | ||||||||
| 1 | These indicators identify whether or not the subject was in the specified analysis for the specific record. Useful when the subject is included in the subject-level population, but there are records for the subject that do not satisfy requirements for the population. \n The valid values of these record-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | ITTRFL | Intent-To-Treat Record-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 2 | These indicators identify whether or not the subject was in the specified analysis for the specific record. Useful when the subject is included in the subject-level population, but there are records for the subject that do not satisfy requirements for the population. \n The valid values of these record-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | SAFRFL | Safety Analysis Record-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 3 | These indicators identify whether or not the subject was in the specified analysis for the specific record. Useful when the subject is included in the subject-level population, but there are records for the subject that do not satisfy requirements for the population. \n The valid values of these record-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | FASRFL | Full Analysis Set Record-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 4 | These indicators identify whether or not the subject was in the specified analysis for the specific record. Useful when the subject is included in the subject-level population, but there are records for the subject that do not satisfy requirements for the population. \n The valid values of these record-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | PPROTRFL | Per-Protocol Record-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 5 | These indicators identify whether or not the subject was in the specified analysis for the specific record. Useful when the subject is included in the subject-level population, but there are records for the subject that do not satisfy requirements for the population. \n The valid values of these record-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | COMPLRFL | Completers Record-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 6 | These indicators identify whether or not the subject was in the specified analysis for the specific parameter. Useful when the subject is included in the subject-level population, but there are parameters for which the subject does not satisfy requirements for the population. \n The valid values of these parameter-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | ITTPFL | Intent-To-Treat Parameter-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 7 | These indicators identify whether or not the subject was in the specified analysis for the specific parameter. Useful when the subject is included in the subject-level population, but there are parameters for which the subject does not satisfy requirements for the population. \n The valid values of these parameter-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | SAFPFL | Safety Analysis Parameter-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 8 | These indicators identify whether or not the subject was in the specified analysis for the specific parameter. Useful when the subject is included in the subject-level population, but there are parameters for which the subject does not satisfy requirements for the population. \n The valid values of these parameter-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | FASPFL | Full Analysis Set Parameter-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 9 | These indicators identify whether or not the subject was in the specified analysis for the specific parameter. Useful when the subject is included in the subject-level population, but there are parameters for which the subject does not satisfy requirements for the population. \n The valid values of these parameter-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | PPROTPFL | Per-Protocol Parameter-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 10 | These indicators identify whether or not the subject was in the specified analysis for the specific parameter. Useful when the subject is included in the subject-level population, but there are parameters for which the subject does not satisfy requirements for the population. \n The valid values of these parameter-level population indicators are Y or null. If a flag is used, the corresponding numeric version (*FN, where 1=Yes) of the flag can also be included. As described in Item 8 in Section 3.1.1 General Variable Conventions, the *FN version of the variable can be included only if the corresponding *FL is also included. \n Additional indicators may also be used; refer to Section 3.1.4, Flag Variable Conventions. | COMPLPFL | Completers Parameter-Level Flag | Char | Population Indicators | BDS | Perm | Y | ||||||||
| 1 | The SDTM domain name or ADaM dataset name that relates to the analysis value (i.e., AVAL or AVALC in a BDS dataset). If the source data is a supplemental qualifier in SDTM, this variable will contain the value of RDOMAIN in SUPP-- or SUPPQUAL. | SRCDOM | Source Data | Char | Datapoint Traceability | BDS | Perm | |||||||||
| 2 | The name of the column (in the domain or dataset identified by SRCDOM) that relates to the analysis value (i.e., AVAL or AVALC in a BDS dataset). In the event that SRCDOM is a SUPPQUAL, then SRCVAR will be populated with the value of the related QNAM. | SRCVAR | Source Variable | Char | Datapoint Traceability | BDS | Perm | |||||||||
| 3 | The sequence number --SEQ or ASEQ of the row (in the domain or dataset identified by SRCDOM) that relates to the analysis value (i.e., AVAL or AVALC in a BDS dataset). In the event that SRCDOM is a SUPPQUAL, then this variable will contain the sequence number of the relevant related domain record. | SRCSEQ | Source Sequence Number | Num | Datapoint Traceability | BDS | Perm |
Overview
Content Tools