| Source Page | TATOBA:ADaM variables |
|---|---|
| Valid Tables | 44 |
| Destination | Library |
| Options |
|
| Output Format | Table |
| Variable Name | Variable Label | Type | Codelist/Controlled Terms | Core | CDISC Notes | Dataset Name | Variable Grouping | Seq. for Order | Class |
|---|---|---|---|---|---|---|---|---|---|
| DOSExxP | Planned Product Dose for Period xx | Num | Perm | Subject-level identifier that represents the planned product dosage for period xx. | ADSL | Dose | 1 | ADSL | |
| DOSExxA | Actual Product Dose for Period xx | Num | Perm | Subject-level identifier that represents the actual product dosage for period xx. | ADSL | Dose | 2 | ADSL | |
| DOSExxU | Units for Dose for Period xx | Char | Perm | The units for DOSExxP and DOSExxA. It is permissible to use suffixes such as "P" and "A" if needed, with labels modified accordingly. | ADSL | Dose | 3 | ADSL | |
| STUDYID | Study Identifier | Char | Req | DM.STUDYID | ADSL | Identifier | 1 | ADSL | |
| USUBJID | Unique Subject Identifier | Char | Req | DM.USUBJID | ADSL | Identifier | 2 | ADSL | |
| SUBJID | Subject Identifier for the Study | Char | Req | DM.SUBJID. SUBJID is required in ADSL, but permissible in other datasets. | ADSL | Identifier | 3 | ADSL | |
| SITEID | Study Site Identifier | Char | Req | DM.SITEID. SITEID is required in ADSL, but permissible in other datasets. | ADSL | Identifier | 4 | ADSL | |
| SITEGRy | Pooled Site Group y | Char | Perm | 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. | ADSL | Identifier | 5 | ADSL | |
| SITEGRyN | Pooled Site Group y (N) | Num | Perm | 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. | ADSL | Identifier | 6 | ADSL | |
| REGIONy | Geographic Region y | Char | Perm | 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". | ADSL | Identifier | 7 | ADSL | |
| REGIONyN | Geographic Region y (N) | Num | Perm | 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. | ADSL | Identifier | 8 | ADSL | |
| APxxSDT | Period xx Start Date | Num | Perm | The starting date of period xx. | ADSL | Period, Subperiod, and Phase Timing | 1 | ADSL | |
| APxxSTM | Period xx Start Time | Num | Perm | The starting time of period xx. | ADSL | Period, Subperiod, and Phase Timing | 2 | ADSL | |
| APxxSDTM | Period xx Start Datetime | Num | Perm | The starting datetime of period xx. | ADSL | Period, Subperiod, and Phase Timing | 3 | ADSL | |
| APxxSDTF | Period xx Start Date Imput. Flag | Char | (DATEFL) | Cond | The level of imputation of period xx start date. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 4 | ADSL |
| APxxSTMF | Period xx Start Time Imput. Flag | Char | (TIMEFL) | Cond | The level of imputation of period xx start time. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 5 | ADSL |
| APxxEDT | Period xx End Date | Num | Perm | The ending date of period xx. | ADSL | Period, Subperiod, and Phase Timing | 6 | ADSL | |
| APxxETM | Period xx End Time | Num | Perm | The ending time of period xx. | ADSL | Period, Subperiod, and Phase Timing | 7 | ADSL | |
| APxxEDTM | Period xx End Datetime | Num | Perm | The ending datetime of period xx. | ADSL | Period, Subperiod, and Phase Timing | 8 | ADSL | |
| APxxEDTF | Period xx End Date Imput. Flag | Char | (DATEFL) | Cond | The level of imputation of period xx end date. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 9 | ADSL |
| APxxETMF | Period xx End Time Imput. Flag | Char | (TIMEFL) | Cond | The level of imputation of period xx end time. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 10 | ADSL |
| PxxSw | Description of Period xx Subperiod w | Char | Perm | Description of analysis subperiod w within period xx. | ADSL | Period, Subperiod, and Phase Timing | 11 | ADSL | |
| PxxSwSDT | Period xx Subperiod w Start Date | Num | Perm | The starting date of subperiod w within period xx. | ADSL | Period, Subperiod, and Phase Timing | 12 | ADSL | |
| PxxSwSTM | Period xx Subperiod w Start Time | Num | Perm | The starting time of subperiod w within period xx. | ADSL | Period, Subperiod, and Phase Timing | 13 | ADSL | |
| PxxSwSDM | Period xx Subperiod w Start Datetime | Num | Perm | The starting datetime of subperiod w within period xx. | ADSL | Period, Subperiod, and Phase Timing | 14 | ADSL | |
| PxxSwSDF | Period xx Subper w Start Date Imput Flag | Char | (DATEFL) | Cond | The level of imputation of the start date for subperiod w within period xx. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 15 | ADSL |
| PxxSwSTF | Period xx Subper w Start Time Imput Flag | Char | (TIMEFL) | Cond | The level of imputation of the start time for subperiod w within period xx. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 16 | ADSL |
| PxxSwEDT | Period xx Subperiod w End Date | Num | Perm | The ending date of subperiod w within period xx. | ADSL | Period, Subperiod, and Phase Timing | 17 | ADSL | |
| PxxSwETM | Period xx Subperiod w End Time | Num | Perm | The ending time of subperiod w within period xx. | ADSL | Period, Subperiod, and Phase Timing | 18 | ADSL | |
| PxxSwEDM | Period xx Subperiod w End Datetime | Num | Perm | The ending datetime of subperiod w within period xx. | ADSL | Period, Subperiod, and Phase Timing | 19 | ADSL | |
| PxxSwEDF | Period xx Subper w End Date Imput Flag | Char | (DATEFL) | Cond | The level of imputation of the end date for subperiod w within period xx. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 20 | ADSL |
| PxxSwETF | Period xx Subper w End Time Imput Flag | Char | (TIMEFL) | Cond | The level of imputation of the end time for subperiod w within period xx. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 21 | ADSL |
| APHASEw | Description of Phase w | Char | Perm | 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 product. | ADSL | Period, Subperiod, and Phase Timing | 22 | ADSL | |
| PHwSDT | Phase w Start Date | Num | Perm | The starting date of phase w. | ADSL | Period, Subperiod, and Phase Timing | 23 | ADSL | |
| PHwSTM | Phase w Start Time | Num | Perm | The starting time of phase w. | ADSL | Period, Subperiod, and Phase Timing | 24 | ADSL | |
| PHwSDTM | Phase w Start Datetime | Num | Perm | The starting datetime of phase w. | ADSL | Period, Subperiod, and Phase Timing | 25 | ADSL | |
| PHwSDTF | Phase w Start Date Imputation Flag | Char | (DATEFL) | Cond | The level of imputation of the start date for phase w. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 26 | ADSL |
| PHwSTMF | Phase w Start Time Imputation Flag | Char | (TIMEFL) | Cond | The level of imputation of the start time for phase w. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 27 | ADSL |
| PHwEDT | Phase w End Date | Num | Perm | The ending date of phase w. | ADSL | Period, Subperiod, and Phase Timing | 28 | ADSL | |
| PHwETM | Phase w End Time | Num | Perm | The ending time of phase w. | ADSL | Period, Subperiod, and Phase Timing | 29 | ADSL | |
| PHwEDTM | Phase w End Datetime | Num | Perm | The ending datetime of phase w. | ADSL | Period, Subperiod, and Phase Timing | 30 | ADSL | |
| PHwEDTF | Phase w End Date Imputation Flag | Char | (DATEFL) | Cond | The level of imputation of the end date for phase w. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 31 | ADSL |
| PHwETMF | Phase w End Time Imputation Flag | Char | (TIMEFL) | Cond | The level of imputation of the end time for phase w. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Period, Subperiod, and Phase Timing | 32 | ADSL |
| FASFL | Full Analysis Set Population Flag | Char | Y, N | Cond | Must be included if FASFL is defined and required per the SAP | ADSL | Population Indicator | 1 | ADSL |
| SAFFL | Safety Population Flag | Char | Y, N | Cond | Must be included if SAFFL is defined and required per the SAP | ADSL | Population Indicator | 2 | ADSL |
| PPROTFL | Per-Protocol Population Flag | Char | Y, N | Cond | Must be included if PPROTFL is defined and required per the SAP | ADSL | Population Indicator | 3 | ADSL |
| COMPLFL | Completers Population Flag | Char | Y, N | Cond | Must be included if COMPLFL is defined and required per the SAP | ADSL | Population Indicator | 4 | ADSL |
| RANDFL | Randomized Population Flag | Char | Y, N | Cond | Must be included if RANDFL is defined and required per the SAP | ADSL | Population Indicator | 5 | ADSL |
| ENRLFL | Enrolled Population Flag | Char | Y, N | Cond | Must be iif ENRLFL is defined and required per the SAP | ADSL | Population Indicator | 6 | ADSL |
| TRTSDT | Date of First Exposure to Product | Num | Cond | Date of first exposure to product 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. | ADSL | Product Timing | 1 | ADSL | |
| TRTSTM | Time of First Exposure to Product | Num | Perm | Time of first exposure to product for a subject in a study. | ADSL | Product Timing | 2 | ADSL | |
| TRTSDTM | Datetime of First Exposure to Product | Num | Cond | Datetime of first exposure to product for a subject in a study. TRTSDT and/or TRTSDTM are required if there is an investigational product. | ADSL | Product Timing | 3 | ADSL | |
| TRTSDTF | Date of First Exposure Imput. Flag | Char | (DATEFL) | Cond | The level of imputation of date of first exposure to product. If TRTSDT (or the date part of TRTSDTM) was imputed, TRTSDTF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Product Timing | 4 | ADSL |
| TRTSTMF | Time of First Exposure Imput. Flag | Char | (TIMEFL) | Cond | The level of imputation of time of first exposure to product. If TRTSTM (or the time part of TRTSDTM) was imputed, TRTSTMF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Product Timing | 5 | ADSL |
| TRTEDT | Date of Last Exposure to Product | Num | Cond | Date of last exposure to product 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. | ADSL | Product Timing | 6 | ADSL | |
| TRTETM | Time of Last Exposure to Product | Num | Perm | Time of last exposure to product for a subject in a study. | ADSL | Product Timing | 7 | ADSL | |
| TRTEDTM | Datetime of Last Exposure to Product | Num | Cond | Datetime of last exposure to product for a subject in a study. TRTEDT and/or TRTEDTM are required if there is an investigational product. | ADSL | Product Timing | 8 | ADSL | |
| TRTEDTF | Date of Last Exposure Imput. Flag | Char | (DATEFL) | Cond | The level of imputation of date of last exposure to product. If TRTEDT (or the date part of TRTEDTM) was imputed, TRTEDTF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Product Timing | 9 | ADSL |
| TRTETMF | Time of Last Exposure Imput. Flag | Char | (TIMEFL) | Cond | The level of imputation of time of last exposure to product. If TRTETM (or the time part of TRTEDTM) was imputed, TRTETMF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Product Timing | 10 | ADSL |
| TRxxSDT | Date of First Exposure in Period xx | Num | Cond | Date of first exposure to product in period xx. TRxxSDT and/or TRxxSDTM are only required in trial designs where multiple product 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 product. | ADSL | Product Timing | 11 | ADSL | |
| TRxxSTM | Time of First Exposure in Period xx | Num | Cond | Starting time of exposure to product in period xx. TRxxSTM and/or TRxxSDTM are only required in trial designs where starting time is important to the analysis and multiple product periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | ADSL | Product Timing | 12 | ADSL | |
| TRxxSDTM | Datetime of First Exposure in Period xx | Num | Cond | Datetime of first exposure to product in period xx. TRxxSDTM is only required in trial designs where multiple product periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | ADSL | Product Timing | 13 | ADSL | |
| TRxxSDTF | Date 1st Exposure Period xx Imput. Flag | Char | (DATEFL) | Cond | The level of imputation of date of first exposure to product in period xx. If TRxxSDT (or the date part of TRxxSDTM) was imputed, TRxxSDTF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Product Timing | 14 | ADSL |
| TRxxSTMF | Time 1st Exposure Period xx Imput. Flag | Char | (TIMEFL) | Cond | The level of imputation of time of first exposure to product in period xx. If TRxxSTM (or the time part of TRxxSDTM) was imputed, TRxxSTMF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Product Timing | 15 | ADSL |
| TRxxEDT | Date of Last Exposure in Period xx | Num | Cond | Date of last exposure to product in period xx. TRxxEDT and/or TRxxEDTM are only required in trial designs where multiple product periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | ADSL | Product Timing | 16 | ADSL | |
| TRxxETM | Time of Last Exposure in Period xx | Num | Cond | Ending time of exposure to product in period xx. TRxxETM and/or TRxxEDTM are only required in trial designs where ending time is important to the analysis and multiple product periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | ADSL | Product Timing | 17 | ADSL | |
| TRxxEDTM | Datetime of Last Exposure in Period xx | Num | Cond | Datetime of last exposure to product in period xx. TRxxEDTM is only required in trial designs where multiple product periods are defined (i.e., required when there is a TRTxxP other than TRT01P). | ADSL | Product Timing | 18 | ADSL | |
| TRxxEDTF | Date Last Exposure Period xx Imput. Flag | Char | (DATEFL) | Cond | The level of imputation of date of last exposure to product in period xx. If TRxxEDT (or the date part of TRxxEDTM) was imputed, TRxxEDTF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Product Timing | 19 | ADSL |
| TRxxETMF | Time Last Exposure Period xx Imput. Flag | Char | (TIMEFL) | Cond | The level of imputation of time of last exposure to product in period xx. If TRxxETM (or the time part of TRxxEDTM) was imputed, TRxxETMF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Product Timing | 20 | ADSL |
| ARM | Description of Planned Arm | Char | Req | DM.ARM | ADSL | Product | 1 | ADSL | |
| ACTARM | Description of Actual Arm | Char | Perm | DM.ACTARM | ADSL | Product | 2 | ADSL | |
| TRTxxP | Planned Product for Period xx | Char | Req | Subject-level identifier that represents the planned product for period xx. In a one-period randomized trial, TRT01P would be the product to which the subject was randomized. TRTxxP might be derived from the SDTM DM variable ARM. At least TRT01P is required. The xx in TRTxxP must be populated in numeric order such that if TRTxxP is present then TRT{xx-1}P must also be present (with the exception of TRT01P where TRT00P cannot be present). | ADSL | Product | 3 | ADSL | |
| TRTxxPN | Planned Product for Period xx (N) | Num | Perm | 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. | ADSL | Product | 4 | ADSL | |
| TRTxxA | Actual Product for Period xx | Char | Cond | Subject-level identifier that represents the actual product for the subject for period xx. Required when actual product does not match planned and there is an analysis of the data as treated. If TRTxxA is present then TRTxxP must also be present. | ADSL | Product | 5 | ADSL | |
| TRTxxAN | Actual Product for Period xx (N) | Num | Perm | 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. | ADSL | Product | 6 | ADSL | |
| TRTSEQP | Planned Sequence of Products | Char | Cond | Required when there is an analysis based on the sequence of products, 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 products or ARM is not fully descriptive (e.g., "GROUP 1," "GROUP 2"). When analyzing based on the sequence of products, TRTSEQP is required even if identical to ARM. | ADSL | Product | 7 | ADSL | |
| TRTSEQPN | Planned Sequence of Products (N) | Num | Perm | 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. | ADSL | Product | 8 | ADSL | |
| TRTSEQA | Actual Sequence of Products | Char | Cond | TRTSEQA is required if a situation occurred in the conduct of the trial where a subject received a sequence of products other than what was planned and there is an analysis based on the sequence of products. | ADSL | Product | 9 | ADSL | |
| TRTSEQAN | Actual Sequence of Products (N) | Num | Perm | 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. | ADSL | Product | 10 | ADSL | |
| TRxxPGy | Planned Pooled Product y for Period xx | Char | Perm | Planned pooled product y for period xx. Useful when planned products (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. | ADSL | Product | 11 | ADSL | |
| TRxxPGyN | Planned Pooled Trt y for Period xx (N) | Num | Perm | 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. | ADSL | Product | 12 | ADSL | |
| TRxxAGy | Actual Pooled Product y for Period xx | Char | Cond | Actual pooled product y for period xx. Required when TRxxPGy is present and TRTxxA is present. | ADSL | Product | 13 | ADSL | |
| TRxxAGyN | Actual Pooled Trt y for Period xx (N) | Num | Perm | 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. | ADSL | Product | 14 | ADSL | |
| TSEQPGy | Planned Pooled Product Sequence y | Char | Perm | Planned pooled product sequence y. Useful when planned product 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. | ADSL | Product | 15 | ADSL | |
| TSEQPGyN | Planned Pooled Product Sequence y (N) | Num | Perm | 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. | ADSL | Product | 16 | ADSL | |
| TSEQAGy | Actual Pooled Product Sequence y | Char | Cond | Actual pooled product sequence y. Required when TSEQPGy is present and TRTSEQA is present. | ADSL | Product | 17 | ADSL | |
| TSEQAGyN | Actual Pooled Product Sequence y (N) | Num | Perm | 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. | ADSL | Product | 18 | ADSL | |
| STRATAR | Strata Used for Randomization | Char | Perm | STRATAR contains the combination of values of the individual stratification factors used for randomization. The exact format should be determined by the applicant. \n This variable is intended for studies that use stratified randomization. \n For example, ">=50, Product experienced, N" | ADSL | Stratification | 1 | ADSL | |
| STRATARN | Strata Used for Randomization (N) | Num | Perm | Numeric representation of STRATAR. For example, STRATARN=3 when STRATAR=">=50, Product 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. | ADSL | Stratification | 2 | ADSL | |
| STRATwD | Description of Stratification Factor w | Char | Perm | 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" | ADSL | Stratification | 3 | ADSL | |
| STRATwR | Strat Factor w Value Used for Rand | Char | Perm | STRATwR is the subject-level value of the "w'th" stratification factor used for randomization. \n For example, STRAT3R="N" | ADSL | Stratification | 4 | ADSL | |
| STRATwRN | Strat Factor w Value Used for Rand (N) | Num | Perm | 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. | ADSL | Stratification | 5 | ADSL | |
| STRATAV | Strata from Verification Source | Char | Perm | 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 applicant. \n For example, ">=50, Product experienced, Y" | ADSL | Stratification | 6 | ADSL | |
| STRATAVN | Strata from Verification Source (N) | Num | Perm | Numeric representation of STRATAV. For example, STRATAVN=4 when STRATVR=">=50, Product 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. | ADSL | Stratification | 7 | ADSL | |
| STRATwV | Strat Factor w Value from Verif Source | Char | Perm | 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" | ADSL | Stratification | 8 | ADSL | |
| STRATwVN | Strat Fact w Val from Verif Source (N) | Num | Perm | 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 | ADSL | Stratification | 9 | ADSL | |
| AGE | Age | Num | Req | DM.AGE. If analysis needs require a derived age that does not match DM.AGE, then AAGE must be added | ADSL | Subject Demographics | 1 | ADSL | |
| AGEU | Age Units | Char | (AGEU) | Req | DM.AGEU | ADSL | Subject Demographics | 2 | ADSL |
| AGEGRy | Pooled Age Group y | Char | Perm | 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". | ADSL | Subject Demographics | 3 | ADSL | |
| AGEGRyN | Pooled Age Group y (N) | Num | Perm | 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. | ADSL | Subject Demographics | 4 | ADSL | |
| AAGE | Analysis Age | Num | Cond | Age used for analysis that may be derived differently than DM.AGE. AAGE is required if age is calculated differently than DM.AGE. | ADSL | Subject Demographics | 5 | ADSL | |
| SEX | Sex | Char | (SEX) | Req | DM.SEX. | ADSL | Subject Demographics | 6 | ADSL |
| RACE | Race | Char | (RACE) | Req | DM.RACE. | ADSL | Subject Demographics | 7 | ADSL |
| RACEGRy | Pooled Race Group y | Char | Perm | Character description of a grouping or pooling of the subject's race for analysis purposes. | ADSL | Subject Demographics | 8 | ADSL | |
| RACEGRyN | Pooled Race Group y (N) | Num | Perm | 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. | ADSL | Subject Demographics | 9 | ADSL | |
| EOSSTT | End of Study Status | Char | (SBJTSTAT) | Perm | The subject's status as of the end of study or data cutoff. Examples: COMPLETED, DISCONTINUED, ONGOING. | ADSL | Trial Experience | 1 | ADSL |
| EOSDT | End of Study Date | Num | Perm | Date subject ended the study—either date of completion or date of discontinuation or data cutoff date for interim analyses. | ADSL | Trial Experience | 2 | ADSL | |
| DCSREAS | Reason for Discontinuation from Study | Char | Perm | Reason for subject's discontinuation from study. The source would most likely be the SDTM DS dataset. Null for subjects who completed the study. | ADSL | Trial Experience | 3 | ADSL | |
| DCSREASP | Reason Spec for Discont from Study | Char | Perm | Additional detail regarding subject's discontinuation from study (e.g., description of "other"). | ADSL | Trial Experience | 4 | ADSL | |
| EOTSTT | End of Product Status | Char | (SBJTSTAT) | Perm | The subject's status as of the end of product or data cutoff. Examples: COMPLETED, DISCONTINUED, ONGOING. | ADSL | Trial Experience | 5 | ADSL |
| DCTREAS | Reason for Discontinuation of Product | Char | Perm | If a subject discontinued product in the study, then this variable indicates the reason for discontinuation. This is for discontinuation of product in the overall study and not to be used for discontinuation reason within individual product periods. | ADSL | Trial Experience | 6 | ADSL | |
| DCTREASP | Reason Specify for Discont of Product | Char | Perm | Additional detail regarding subject's discontinuation from product (e.g., description of "other"). | ADSL | Trial Experience | 7 | ADSL | |
| EOTxxSTT | End of Product Status in Period xx | Char | (SBJTSTAT) | Perm | The subject's product status as of the end of period xx, or data cutoff if within period xx. Examples: COMPLETED, DISCONTINUED, ONGOING. | ADSL | Trial Experience | 8 | ADSL |
| DCTxxRS | Reason for Discont of Prd in Period xx | Char | Perm | Reason for discontinuing product in period xx. | ADSL | Trial Experience | 9 | ADSL | |
| DCTxxRSP | Reason Spec for Disc of Prd in Period xx | Char | Perm | Additional detail regarding subject's discontinuation of product in period xx (e.g., description of "other"). | ADSL | Trial Experience | 10 | ADSL | |
| EOPxxSTT | End of Period xx Status | Char | (SBJTSTAT) | Perm | The subject's status as of the end of period xx, or data cutoff if within period xx. Examples: COMPLETED, DISCONTINUED, ONGOING. | ADSL | Trial Experience | 11 | ADSL |
| DCPxxRS | Reason for Discont from Period xx | Char | Perm | Reason for discontinuing analysis period xx. | ADSL | Trial Experience | 12 | ADSL | |
| DCPxxRSP | Reason Spec for Discont from Period xx | Char | Perm | Additional detail regarding subject's discontinuation from period xx (e.g., description of "other"). | ADSL | Trial Experience | 13 | ADSL | |
| RFICDT | Date of Informed Consent | Num | Perm | Date subject gave informed consent. Generally equivalent to DM.RFICDTC. | ADSL | Trial Experience | 14 | ADSL | |
| ENRLDT | Date of Enrollment | Num | Perm | Date of subject's enrollment into trial. | ADSL | Trial Experience | 15 | ADSL | |
| RANDDT | Date of Randomization | Num | Cond | Required in randomized trials. | ADSL | Trial Experience | 16 | ADSL | |
| RFICyDT | Date of Informed Consent y | Num | Perm | 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. | ADSL | Trial Experience | 17 | ADSL | |
| ENRLyDT | Date of Enrollment y | Num | Perm | 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. | ADSL | Trial Experience | 18 | ADSL | |
| RANDyDT | Date of Randomization y | Num | Perm | 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. | ADSL | Trial Experience | 19 | ADSL | |
| LSTALVDT | Date Last Known Alive | Num | Perm | 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. | ADSL | Trial Experience | 20 | ADSL | |
| TRCMP | Product Compliance (%) | Num | Perm | Overall percent compliance with product in the trial. TRCMP may be useful for inclusion in ADSL for reasons such as defining subgroups and/or populations. | ADSL | Trial Experience | 21 | ADSL | |
| TRCMPGy | Product Compliance (%) Group y | Char | Perm | Grouping "y" of TRCMP, product compliance percentage. | ADSL | Trial Experience | 22 | ADSL | |
| TRCMPGyN | Product Compliance (%) Group y (N) | Num | Perm | Numeric representation of product 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. | ADSL | Trial Experience | 23 | ADSL | |
| TRxxDURD | Product Duration in Period xx (Days) | Num | Perm | Product 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. | ADSL | Trial Experience | 24 | ADSL | |
| TRxxDURM | Product Duration in Period xx (Months) | Num | Perm | Product 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. | ADSL | Trial Experience | 25 | ADSL | |
| TRxxDURY | Product Duration in Period xx (Years) | Num | Perm | Product 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. | ADSL | Trial Experience | 26 | ADSL | |
| TRTDURD | Total Product Duration (Days) | Num | Perm | Total product 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. | ADSL | Trial Experience | 27 | ADSL | |
| TRTDURM | Total Product Duration (Months) | Num | Perm | Total product 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. | ADSL | Trial Experience | 28 | ADSL | |
| TRTDURY | Total Product Duration (Years) | Num | Perm | Total product 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. | ADSL | Trial Experience | 29 | ADSL | |
| DTHDT | Date of Death | Num | Perm | Date of subject's death. Derived from DM.DTHDTC. | ADSL | Trial Experience | 30 | ADSL | |
| DTHDTF | Date of Death Imputation Flag | Char | (DATEFL) | Cond | Imputation flag for date of subject's death. If DTHDT was imputed, DTHDTF must be populated and is required. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | ADSL | Trial Experience | 31 | ADSL |
| DTHCAUS | Cause of Death | Char | Perm | Cause of Death. | ADSL | Trial Experience | 32 | ADSL | |
| DTHCAUSN | Cause of Death (N) | Num | Perm | 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. | ADSL | Trial Experience | 33 | ADSL | |
| DTHCGRy | Cause of Death Group y | Char | Perm | Grouping "y" of DTHCAUS, the subject's cause of death. | ADSL | Trial Experience | 34 | ADSL | |
| DTHCGRyN | Cause of Death Group y (N) | Num | Perm | 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. | ADSL | Trial Experience | 35 | ADSL | |
| DTYPE | Derivation Type | Char | (DTYPE) | Cond | 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. \n Some examples of DTYPE values:LOCF = last observation carried forwardWOCF = worst observation carried forwardAVERAGE = average of values | Analysis Descriptor | 1 | BDS | |
| CRITy | Analysis Criterion y | Char | Perm | 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 2.9.9.4, Identification of Records Used for Analysis, for additional discussion of CRITy, CRITyFL and CRITyFN. | Analysis Parameter Criteria | 1 | BDS | ||
| CRITyFL | Criterion y Evaluation Result Flag | Char | Y or Y, N | Cond | 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 2.9.9.4, Identification of Records Used for Analysis, for additional discussion. | Analysis Parameter Criteria | 2 | BDS | |
| CRITyFN | Criterion y Evaluation Result Flag (N) | Num | 1 or 1, 0 | Perm | 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. | Analysis Parameter Criteria | 3 | BDS | |
| MCRITy | Analysis Multi-Response Criterion y | Char | Perm | 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 2.9.9.4, Identification of Records Used for Analysis, for additional discussion of MCRITy, MCRITyML, and MCRITyMN. | Analysis Parameter Criteria | 4 | BDS | ||
| MCRITyML | Multi-Response Criterion y Evaluation | Char | Cond | 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 applicant-defined. Required if MCRITy is present. | Analysis Parameter Criteria | 5 | BDS | ||
| MCRITyMN | Multi-Response Criterion y Eval (N) | Num | Perm | Numeric representation of MCRITyML. There must be a one-to-one relationship between MCRITyMN and MCRITyML within a parameter. Content is applicant-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. | Analysis Parameter Criteria | 6 | BDS | ||
| PARAM | Parameter | Char | Req | 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. | Analysis Parameter | 1 | BDS | ||
| PARAMCD | Parameter Code | Char | Req | 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 2.9.3.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. | Analysis Parameter | 2 | BDS | ||
| PARAMN | Parameter (N) | Num | Perm | 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. | Analysis Parameter | 3 | BDS | ||
| PARCATy | Parameter Category y | Char | Perm | 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). | Analysis Parameter | 4 | BDS | ||
| PARCATyN | Parameter Category y (N) | Num | Perm | 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. | Analysis Parameter | 5 | BDS | ||
| AVAL | Analysis Value | Num | Cond | 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. | Analysis Parameter | 6 | BDS | ||
| AVALC | Analysis Value (C) | Char | Cond | 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. | Analysis Parameter | 7 | BDS | ||
| AVALCATy | Analysis Value Category y | Char | Perm | 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. | Analysis Parameter | 8 | BDS | ||
| AVALCAyN | Analysis Value Category y (N) | Num | Perm | 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. | Analysis Parameter | 9 | BDS | ||
| BASE | Baseline Value | Num | Cond | 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. | Analysis Parameter | 10 | BDS | ||
| BASEC | Baseline Value (C) | Char | Perm | 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. | Analysis Parameter | 11 | BDS | ||
| BASECATy | Baseline Category y | Char | Perm | 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). | Analysis Parameter | 12 | BDS | ||
| BASECAyN | Baseline Category y (N) | Num | Perm | 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. | Analysis Parameter | 13 | BDS | ||
| BASETYPE | Baseline Type | Char | Cond | 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. | Analysis Parameter | 14 | BDS | ||
| CHG | Change from Baseline | Num | Perm | 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. | Analysis Parameter | 15 | BDS | ||
| CHGCATy | Change from Baseline Category y | Char | Perm | 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. | Analysis Parameter | 16 | BDS | ||
| CHGCATyN | Change from Baseline Category y (N) | Num | Perm | 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. | Analysis Parameter | 17 | BDS | ||
| PCHG | Percent Change from Baseline | Num | Perm | 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. | Analysis Parameter | 18 | BDS | ||
| PCHGCATy | Percent Chg from Baseline Category y | Char | Perm | 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. | Analysis Parameter | 19 | BDS | ||
| PCHGCAyN | Percent Chg from Baseline Category y (N) | Num | Perm | 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. | Analysis Parameter | 20 | BDS | ||
| R2BASE | Ratio to Baseline | Num | Perm | 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. | Analysis Parameter | 21 | BDS | ||
| R2AyLO | Ratio to Analysis Range y Lower Limit | Num | Perm | 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. | Analysis Parameter | 22 | BDS | ||
| R2AyHI | Ratio to Analysis Range y Upper Limit | Num | Perm | 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. | Analysis Parameter | 23 | BDS | ||
| SHIFTy | Shift y | Char | Perm | 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. | Analysis Parameter | 24 | BDS | ||
| SHIFTyN | Shift y (N) | Num | Perm | 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. | Analysis Parameter | 25 | BDS | ||
| BCHG | Change to Baseline | Num | Perm | 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. | Analysis Parameter | 26 | BDS | ||
| BCHGCATy | Change to Baseline Category y | Char | Perm | 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. | Analysis Parameter | 27 | BDS | ||
| BCHGCAyN | Change to Baseline Category y (N) | Num | Perm | 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. | Analysis Parameter | 28 | BDS | ||
| PBCHG | Percent Change to Baseline | Num | Perm | 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 | Analysis Parameter | 29 | BDS | ||
| PBCHGCAy | Percent Change to Baseline Category y | Char | Perm | 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. | Analysis Parameter | 30 | BDS | ||
| PBCHGCyN | Percent Change to Baseline Category y (N) | Num | Perm | 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. | Analysis Parameter | 31 | BDS | ||
| AWRANGE | Analysis Window Valid Relative Range | Char | Perm | The range of values that are valid for a given analysis timepoint (a given value of AVISIT). For example, "5-9 DAYS". | Analysis Visit Windowing | 1 | BDS | ||
| AWTARGET | Analysis Window Target | Num | Perm | The target or most desired analysis relative day (ADY) value or analysis relative time (ARELTM) value for a given value of AVISIT. | Analysis Visit Windowing | 2 | BDS | ||
| AWTDIFF | Analysis Window Diff from Target | Num | Perm | 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. | Analysis Visit Windowing | 3 | BDS | ||
| AWLO | Analysis Window Beginning Timepoint | Num | Perm | 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". | Analysis Visit Windowing | 4 | BDS | ||
| AWHI | Analysis Window Ending Timepoint | Num | Perm | 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". | Analysis Visit Windowing | 5 | BDS | ||
| AWU | Analysis Window Unit | Char | Perm | Unit used for AWTARGET, AWTDIFF, AWLO and AWHI. Examples: DAYS, HOURS. | Analysis Visit Windowing | 6 | BDS | ||
| SRCDOM | Source Data | Char | Perm | 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. | Datapoint Traceability | 1 | BDS | ||
| SRCVAR | Source Variable | Char | Perm | 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. | Datapoint Traceability | 2 | BDS | ||
| SRCSEQ | Source Sequence Number | Num | Perm | 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. | Datapoint Traceability | 3 | BDS | ||
| ABLFL | Baseline Record Flag | Char | Y | Cond | Character indicator to identify the baseline record for each subject, parameter, and baseline type (BASETYPE) combination. See Section 2.9.6.4, Analysis Parameter Variables for BDS Datasets. ABLFL is required if BASE is present in the dataset. \n A baseline record may be derived (e.g., 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. | Flag | 1 | BDS | |
| ABLFN | Baseline Record Flag (N) | Num | 1 | Perm | 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. | Flag | 2 | BDS | |
| ANLzzFL | Analysis Flag zz | Char | Y | Cond | 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. | Flag | 3 | BDS | |
| ANLzzFN | Analysis Flag zz (N) | Num | 1 | Perm | 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. | Flag | 4 | BDS | |
| ONTRTFL | On Product Record Flag | Char | Y | Perm | Character indicator of whether the observation occurred while the subject was on product. ONTRTFL is producer-defined, and its definition may vary across datasets in a study based on analysis needs. | Flag | 5 | BDS | |
| ONTRTFN | On Product Record Flag (N) | Num | 1 | Perm | 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. | Flag | 6 | BDS | |
| LVOTFL | Last Value On Product Record Flag | Char | Y | Perm | Character indicator of the subject's last non-missing value on product for each parameter. | Flag | 7 | BDS | |
| LVOTFN | Last Value On Product Record Flag (N) | Num | 1 | Perm | 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. | Flag | 8 | BDS | |
| STUDYID | Study Identifier | Char | Req | DM.STUDYID, ADSL STUDYID, and/or STUDYID from another ADaM or SDTM dataset appropriate to the analysis. | Identifier | 1 | BDS | ||
| USUBJID | Unique Subject Identifier | Char | Req | DM.USUBJID, ADSL.USUBJID, and/or USUBJID from another ADaM or SDTM dataset appropriate to the analysis. | Identifier | 2 | BDS | ||
| SUBJID | Subject Identifier for the Study | Char | Perm | 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. | Identifier | 3 | BDS | ||
| SITEID | Study Site Identifier | Char | Perm | 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. | Identifier | 4 | BDS | ||
| ASEQ | Analysis Sequence Number | Num | Perm | 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. | Identifier | 5 | BDS | ||
| APERSDT | Period Start Date | Num | Perm | The starting date for the period defined by APERIOD. | Period, Subperiod, and Phase Start and End Timing | 1 | BDS | ||
| APERSTM | Period Start Time | Num | Perm | The starting time for the period defined by APERIOD. | Period, Subperiod, and Phase Start and End Timing | 2 | BDS | ||
| APERSDTM | Period Start Datetime | Num | Perm | The starting datetime for the period defined by APERIOD. | Period, Subperiod, and Phase Start and End Timing | 3 | BDS | ||
| APERSDTF | Period Start Date Imput. Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Period, Subperiod, and Phase Start and End Timing | 4 | BDS | |
| APERSTMF | Period Start Time Imput. Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Period, Subperiod, and Phase Start and End Timing | 5 | BDS | |
| APEREDT | Period End Date | Num | Perm | The ending date for the period defined by APERIOD. | Period, Subperiod, and Phase Start and End Timing | 6 | BDS | ||
| APERETM | Period End Time | Num | Perm | The ending time for the period defined by APERIOD. | Period, Subperiod, and Phase Start and End Timing | 7 | BDS | ||
| APEREDTM | Period End Datetime | Num | Perm | The ending datetime for the period defined by APERIOD. | Period, Subperiod, and Phase Start and End Timing | 8 | BDS | ||
| APEREDTF | Period End Date Imput. Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Period, Subperiod, and Phase Start and End Timing | 9 | BDS | |
| APERETMF | Period End Time Imput. Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Period, Subperiod, and Phase Start and End Timing | 10 | BDS | |
| ASPRSDT | Subperiod Start Date | Num | Perm | The starting date for the subperiod defined by ASPER. | Period, Subperiod, and Phase Start and End Timing | 11 | BDS | ||
| ASPRSTM | Subperiod Start Time | Num | Perm | The starting time for the subperiod defined by ASPER. | Period, Subperiod, and Phase Start and End Timing | 12 | BDS | ||
| ASPRSDTM | Subperiod Start Datetime | Num | Perm | The starting datetime for the subperiod defined by ASPER. | Period, Subperiod, and Phase Start and End Timing | 13 | BDS | ||
| ASPRSDTF | Subperiod Start Date Imput. Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables . | Period, Subperiod, and Phase Start and End Timing | 14 | BDS | |
| ASPRSTMF | Subperiod Start Time Imput. Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables . | Period, Subperiod, and Phase Start and End Timing | 15 | BDS | |
| ASPREDT | Subperiod End Date | Num | Perm | The ending date for the subperiod defined by ASPER. | Period, Subperiod, and Phase Start and End Timing | 16 | BDS | ||
| ASPRETM | Subperiod End Time | Num | Perm | The ending time for the subperiod defined by ASPER. | Period, Subperiod, and Phase Start and End Timing | 17 | BDS | ||
| ASPREDTM | Subperiod End Datetime | Num | Perm | The ending datetime for the subperiod defined by ASPER. | Period, Subperiod, and Phase Start and End Timing | 18 | BDS | ||
| ASPREDTF | Subperiod End Date Imput. Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables . | Period, Subperiod, and Phase Start and End Timing | 19 | BDS | |
| ASPRETMF | Subperiod End Time Imput. Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables . | Period, Subperiod, and Phase Start and End Timing | 20 | BDS | |
| PHSDT | Phase Start Date | Num | Perm | The starting date for the phase defined by APHASE. | Period, Subperiod, and Phase Start and End Timing | 21 | BDS | ||
| PHSTM | Phase Start Time | Num | Perm | The starting time for the phase defined by APHASE. | Period, Subperiod, and Phase Start and End Timing | 22 | BDS | ||
| PHSDTM | Phase Start Datetime | Num | Perm | The starting datetime for the phase defined by APHASE. | Period, Subperiod, and Phase Start and End Timing | 23 | BDS | ||
| PHSDTF | Phase Start Date Imput. Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables . | Period, Subperiod, and Phase Start and End Timing | 24 | BDS | |
| PHSTMF | Phase Start Time Imput. Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables . | Period, Subperiod, and Phase Start and End Timing | 25 | BDS | |
| PHEDT | Phase End Date | Num | Perm | The ending date for the phase defined by APHASE. | Period, Subperiod, and Phase Start and End Timing | 26 | BDS | ||
| PHETM | Phase End Time | Num | Perm | The ending time for the phase defined by APHASE. | Period, Subperiod, and Phase Start and End Timing | 27 | BDS | ||
| PHEDTM | Phase End Datetime | Num | Perm | The ending datetime for the phase defined by APHASE. | Period, Subperiod, and Phase Start and End Timing | 28 | BDS | ||
| PHEDTF | Phase End Date Imput. Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables . | Period, Subperiod, and Phase Start and End Timing | 29 | BDS | |
| PHETMF | Phase End Time Imput. Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables . | Period, Subperiod, and Phase Start and End Timing | 30 | BDS | |
| ITTRFL | Intent-To-Treat Record-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 1 | BDS | |
| SAFRFL | Safety Analysis Record-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 2 | BDS | |
| FASRFL | Full Analysis Set Record-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 3 | BDS | |
| PPROTRFL | Per-Protocol Record-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 4 | BDS | |
| COMPLRFL | Completers Record-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 5 | BDS | |
| ITTPFL | Intent-To-Treat Parameter-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 6 | BDS | |
| SAFPFL | Safety Analysis Parameter-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 7 | BDS | |
| FASPFL | Full Analysis Set Parameter-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 8 | BDS | |
| PPROTPFL | Per-Protocol Parameter-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 9 | BDS | |
| COMPLPFL | Completers Parameter-Level Flag | Char | Y | Perm | 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 , 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, . | Population Indicators | 10 | BDS | |
| DOSEP | Planned Product Dose | Num | Perm | DOSEP represents the planned product dosage associated with the record. | Record-Level Dose | 1 | BDS | ||
| DOSCUMP | Cumulative Planned Product Dose | Num | Perm | Cumulative planned dosage of product for the subject at the point in time of the record (e.g., ADT). | Record-Level Dose | 2 | BDS | ||
| DOSEA | Actual Product Dose | Num | Perm | DOSEA represents the actual product dosage associated with the record. | Record-Level Dose | 3 | BDS | ||
| DOSCUMA | Cumulative Actual Product Dose | Num | Perm | Cumulative actual dosage of product for the subject at the point in time of the record (e.g., ADT). | Record-Level Dose | 4 | BDS | ||
| DOSEU | Product Dose Units | Char | Perm | 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. | Record-Level Dose | 5 | BDS | ||
| TRTP | Planned Product | Char | Cond | TRTP is a record-level identifier that represents the planned product attributed to a record for analysis purposes. TRTP indicates how product 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 product variables in ADSL (e.g., TRTxxP, TRTSEQP, TRxxPGy). \n As noted previously, at least one product variable is required even in non-randomized trials. This requirement is satisfied by any subject-level or record-level product variables (e.g., TRTxxP, TRTP, TRTA). Even if not used for analysis, any ADSL product variable may be included in the BDS dataset. | Record-Level Product | 1 | BDS | ||
| TRTPN | Planned Product (N) | Num | Perm | 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. | Record-Level Product | 2 | BDS | ||
| TRTA | Actual Product | Char | Cond | TRTA is a record-level identifier that represents the actual product attributed to a record for analysis purposes. TRTA indicates how product 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 product variables in ADSL (e.g., TRTxxA, TRTSEQA, TRxxAGy). \n As noted previously, at least one product variable is required. This requirement is satisfied by any subject-level or record-level product variables (e.g., TRTxxP, TRTP, TRTA). Even if not used for analysis, any ADSL product variable may be included in the BDS dataset. | Record-Level Product | 3 | BDS | ||
| TRTAN | Actual Product (N) | Num | Perm | 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. | Record-Level Product | 4 | BDS | ||
| TRTPGy | Planned Pooled Product y | Char | Perm | TRTPGy is the planned pooled product 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 products (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. | Record-Level Product | 5 | BDS | ||
| TRTPGyN | Planned Pooled Product y (N) | Num | Perm | 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. | Record-Level Product | 6 | BDS | ||
| TRTAGy | Actual Pooled Product y | Char | Cond | TRTAGy is the actual pooled product 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. | Record-Level Product | 7 | BDS | ||
| TRTAGyN | Actual Pooled Product y (N) | Num | Perm | 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. | Record-Level Product | 8 | BDS | ||
| *DT | {Date} | Num | Perm | Analysis date not directly characterizing AVAL and/or AVALC in numeric format. | Suffixes for User-Defined Timing | 1 | BDS | ||
| *TM | {Time} | Num | Perm | Analysis time not directly characterizing AVAL and/or AVALC in numeric format. | Suffixes for User-Defined Timing | 2 | BDS | ||
| *DTM | {Datetime} | Num | Perm | Analysis datetime not directly characterizing AVAL and/or AVALC in numeric format. | Suffixes for User-Defined Timing | 3 | BDS | ||
| *ADY | {Relative Day} | Num | Perm | Analysis relative day not directly characterizing AVAL and/or AVALC. | Suffixes for User-Defined Timing | 4 | BDS | ||
| *DTF | {Date Imputation Flag} | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Suffixes for User-Defined Timing | 5 | BDS | |
| *TMF | {Time Imputation Flag} | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Suffixes for User-Defined Timing | 6 | BDS | |
| *SDT | {Start Date} | Num | Perm | Starting analysis date not directly characterizing AVAL and/or AVALC in numeric format. | Suffixes for User-Defined Timing | 7 | BDS | ||
| *STM | {Start Time} | Num | Perm | Starting analysis time not directly characterizing AVAL and/or AVALC in numeric format. | Suffixes for User-Defined Timing | 8 | BDS | ||
| *SDTM | {Start Datetime} | Num | Perm | Starting analysis datetime not directly characterizing AVAL and/or AVALC in numeric format. | Suffixes for User-Defined Timing | 9 | BDS | ||
| *SDY | {Relative Start Day} | Num | Perm | Starting analysis relative day not directly characterizing AVAL and/or AVALC. | Suffixes for User-Defined Timing | 10 | BDS | ||
| *SDTF | {Start Date Imputation Flag} | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Suffixes for User-Defined Timing | 11 | BDS | |
| *STMF | {Start Time Imputation Flag} | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Suffixes for User-Defined Timing | 12 | BDS | |
| *EDT | {End Date} | Num | Perm | Ending analysis date not directly characterizing AVAL and/or AVALC in numeric format. If both *SDT and *EDT are populated then *SDT must be less than or equal to *EDT. | Suffixes for User-Defined Timing | 13 | BDS | ||
| *ETM | {End Time} | Num | Perm | Ending analysis time not directly characterizing AVAL and/or AVALC in numeric format. | Suffixes for User-Defined Timing | 14 | BDS | ||
| *EDTM | {End Datetime} | Num | Perm | Ending analysis datetime not directly characterizing AVAL and/or AVALC in numeric format. If both *SDTM and *EDTM are populated then *SDTM must be less than or equal to *EDTM. | Suffixes for User-Defined Timing | 15 | BDS | ||
| *EDY | {Relative End Day} | Num | Perm | Ending analysis relative day not directly characterizing AVAL and/or AVALC. If both *SDY and *EDY are populated then *SDY must be less than or equal to *EDY | Suffixes for User-Defined Timing | 16 | BDS | ||
| *EDTF | {End Date Imputation Flag} | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Suffixes for User-Defined Timing | 17 | BDS | |
| *ETMF | {End Time Imputation Flag} | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Suffixes for User-Defined Timing | 18 | BDS | |
| STARTDT | Time-to-Event Origin Date for Subject | Num | Perm | 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. | Time-to-Event | 1 | BDS | ||
| STARTDTM | Time-to-Event Origin Datetime | Num | Perm | 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. | Time-to-Event | 2 | BDS | ||
| STARTDTF | Origin Date Imputation Flag | Char | (DATEFL) | Cond | The level of imputation of the start date. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | Time-to-Event | 3 | BDS | |
| STARTTMF | Origin Time Imputation Flag | Char | (TIMEFL) | Cond | The level of imputation of the start time. See Section 2.9.3.3, Date and Time Imputation Flag Variables. | Time-to-Event | 4 | BDS | |
| CNSR | Censor | Num | Cond | 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. | Time-to-Event | 5 | BDS | ||
| EVNTDESC | Event or Censoring Description | Char | Perm | Description of the event of interest or censoring reason for the subject within the parameter. | Time-to-Event | 6 | BDS | ||
| CNSDTDSC | Censor Date Description | Char | Perm | Describes the circumstance represented by the censoring date if different from the event date that warrants censoring. | Time-to-Event | 7 | BDS | ||
| ADT | Analysis Date | Num | Cond | The date associated with AVAL and/or AVALC in numeric format. | Timing | 1 | BDS | ||
| ATM | Analysis Time | Num | Cond | The time associated with AVAL and/or AVALC in numeric format. | Timing | 2 | BDS | ||
| ADTM | Analysis Datetime | Num | Cond | The datetime associated with AVAL and/or AVALC in numeric format. | Timing | 3 | BDS | ||
| ADY | Analysis Relative Day | Num | Cond | The relative day of AVAL and/or AVALC. The number of days from an anchor date (not necessarily DM.RFSTDTC) to ADT. See Section 2.9.3.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). | Timing | 4 | BDS | ||
| ADTF | Analysis Date Imputation Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Timing | 5 | BDS | |
| ATMF | Analysis Time Imputation Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Timing | 6 | BDS | |
| ASTDT | Analysis Start Date | Num | Cond | 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. | Timing | 7 | BDS | ||
| ASTTM | Analysis Start Time | Num | Cond | 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. | Timing | 8 | BDS | ||
| ASTDTM | Analysis Start Datetime | Num | Cond | 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. | Timing | 9 | BDS | ||
| ASTDY | Analysis Start Relative Day | Num | Cond | The number of days from an anchor date (not necessarily DM.RFSTDTC) to ASTDT. See Section 2.9.3.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). | Timing | 10 | BDS | ||
| ASTDTF | Analysis Start Date Imputation Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Timing | 11 | BDS | |
| ASTTMF | Analysis Start Time Imputation Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Timing | 12 | BDS | |
| AENDT | Analysis End Date | Num | Cond | The end date associated with AVAL and/or AVALC. See also ASTDT. If both ASTDT and AENDT are populated then ASTDT must less than or equal to AENDT. | Timing | 13 | BDS | ||
| AENTM | Analysis End Time | Num | Cond | The end time associated with AVAL and/or AVALC. See also ASTTM. | Timing | 14 | BDS | ||
| AENDTM | Analysis End Datetime | Num | Cond | The end datetime associated with AVAL and/or AVALC. See also ASTDTM. If both ASTDTM and AENDTM are populated then ASTDTM must less than or equal to AENDTM. | Timing | 15 | BDS | ||
| AENDY | Analysis End Relative Day | Num | Cond | The number of days from an anchor date (not necessarily DM.RFSTDTC) to AENDT. See Section 2.9.3.2, Timing Variable Conventions. If a dataset contains more than 1 record per parameter per subject, then an SDTM or ADaM relative timing variable must be present (AENDY would meet this requirement). If both ASTDY and AENDY are populated then ASTDY must be less than or equal to AENDY | Timing | 16 | BDS | ||
| AENDTF | Analysis End Date Imputation Flag | Char | (DATEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Timing | 17 | BDS | |
| AENTMF | Analysis End Time Imputation Flag | Char | (TIMEFL) | Cond | 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 2.9.3.3, Date and Time Imputation Flag Variables. | Timing | 18 | BDS | |
| AVISIT | Analysis Visit | Char | Cond | 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 2.9.6.10, 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). | Timing | 19 | BDS | ||
| AVISITN | Analysis Visit (N) | Num | Perm | 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. | Timing | 20 | BDS | ||
| ATPT | Analysis Timepoint | Char | Cond | 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). | Timing | 21 | BDS | ||
| ATPTN | Analysis Timepoint (N) | Num | Perm | 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. | Timing | 22 | BDS | ||
| ATPTREF | Analysis Timepoint Reference | Char | Perm | Description of the fixed reference point referred to by ATPT/ATPTN (e.g., time of dose). | Timing | 23 | BDS | ||
| APHASE | Phase | Char | Perm | 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 PRODUCT, 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 product. The value of APHASE (if populated) must be one of the values found in the ADSL APHASEw variables. | Timing | 24 | BDS | ||
| APHASEN | Phase (N) | Num | Perm | 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. | Timing | 25 | BDS | ||
| APERIOD | Period | Num | Cond | 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 | Timing | 26 | BDS | ||
| APERIODC | Period (C) | Char | Perm | 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. | Timing | 27 | BDS | ||
| ASPER | Subperiod within Period | Num | Perm | 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 | Timing | 28 | BDS | ||
| ASPERC | Subperiod within Period (C) | Char | Perm | 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. | Timing | 29 | BDS | ||
| ARELTM | Analysis Relative Time | Num | Perm | 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. | Timing | 30 | BDS | ||
| ARELTMU | Analysis Relative Time Unit | Char | Perm | The units of ARELTM. For example, "HOURS" or "MINUTES." ARELTMU is required if ARELTM is present. | Timing | 31 | BDS | ||
| ATOXGR | Analysis Toxicity Grade | Char | Perm | Toxicity grade of AVAL or AVALC for analysis; may be based on SDTM --TOXGR or an imputed or assigned value. | Toxicity and Range | 1 | BDS | ||
| ATOXGRN | Analysis Toxicity Grade (N) | Num | Perm | 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. | Toxicity and Range | 2 | BDS | ||
| BTOXGR | Baseline Toxicity Grade | Char | Perm | ATOXGR of the baseline record identified by ABLFL. | Toxicity and Range | 3 | BDS | ||
| BTOXGRN | Baseline Toxicity Grade (N) | Num | Perm | 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. | Toxicity and Range | 4 | BDS | ||
| ANRIND | Analysis Reference Range Indicator | Char | Perm | 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. | Toxicity and Range | 5 | BDS | ||
| BNRIND | Baseline Reference Range Indicator | Char | Perm | ANRIND of the baseline record identified by ABLFL. | Toxicity and Range | 6 | BDS | ||
| ANRLO | Analysis Normal Range Lower Limit | Num | Perm | Normal range lower limit for analysis; may be based on SDTM --NRLO or an imputed or assigned value. | Toxicity and Range | 7 | BDS | ||
| ANRLOC | Analysis Normal Range Lower Limit (C) | Char | Perm | 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. | Toxicity and Range | 8 | BDS | ||
| ANRHI | Analysis Normal Range Upper Limit | Num | Perm | Normal range upper limit for analysis; may be based on SDTM --NRHI or an imputed or assigned value. | Toxicity and Range | 9 | BDS | ||
| ANRHIC | Analysis Normal Range Upper Limit (C) | Char | Perm | 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. | Toxicity and Range | 10 | BDS | ||
| AyLO | Analysis Range y Lower Limit | Num | Cond | 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. | Toxicity and Range | 11 | BDS | ||
| AyLOC | Analysis Range y Lower Limit (C) | Char | Perm | 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. | Toxicity and Range | 12 | BDS | ||
| AyHI | Analysis Range y Upper Limit | Num | Cond | 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. | Toxicity and Range | 13 | BDS | ||
| AyHIC | Analysis Range y Upper Limit (C) | Char | Perm | 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. | Toxicity and Range | 14 | BDS | ||
| AyIND | Analysis Range y Indicator | Char | Perm | 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. | Toxicity and Range | 15 | BDS | ||
| ByIND | Baseline Analysis Range y Indicator | Char | Perm | AyIND of the baseline record identified by ABLFL. | Toxicity and Range | 16 | BDS | ||
| ATOXGRL | Analysis Toxicity Grade Low | Char | Perm | 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. | Toxicity and Range | 17 | BDS | ||
| ATOXGRLN | Analysis Toxicity Grade Low (N) | Num | Perm | 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. | Toxicity and Range | 18 | BDS | ||
| ATOXGRH | Analysis Toxicity Grade High | Char | Perm | 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. | Toxicity and Range | 19 | BDS | ||
| ATOXGRHN | Analysis Toxicity Grade High (N) | Num | Perm | 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. | Toxicity and Range | 20 | BDS | ||
| BTOXGRL | Baseline Toxicity Grade Low | Char | Perm | ATOXGRL of the baseline record identified by ABLFL. | Toxicity and Range | 21 | BDS | ||
| BTOXGRLN | Baseline Toxicity Grade Low (N) | Num | Perm | 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. | Toxicity and Range | 22 | BDS | ||
| BTOXGRH | Baseline Toxicity Grade High | Char | Perm | ATOXGRH of the baseline record identified by ABLFL. | Toxicity and Range | 23 | BDS | ||
| BTOXGRHN | Baseline Toxicity Grade High (N) | Num | Perm | 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. | Toxicity and Range | 24 | BDS | ||
| ATOXDSCL | Analysis Toxicity Description Low | Char | Perm | 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. | Toxicity and Range | 25 | BDS | ||
| ATOXDSCH | Analysis Toxicity Description High | Char | Perm | 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. | Toxicity and Range | 26 | BDS | ||
| STUDYID | Study Identifier | Char | Req | XX.STUDYID | Identifier | 1 | OCCDS | ||
| USUBJID | Unique Subject Identifier | Char | Req | XX.USUBJID | Identifier | 2 | OCCDS | ||
| SUBJID | Subject Identifier for the Study | Char | Perm | ADSL.SUBJID | Identifier | 3 | OCCDS | ||
| SITEID | Study Site Identifier | Char | Perm | ADSL.SITEID | Identifier | 4 | OCCDS | ||
| --SEQ | Sequence Number | Num | Cond | XX.--SEQ \n Identifies the sequence number in SDTM domain XX that is the source for this row. This variable would be copied unchanged from the SDTM domain XX. Required for traceability back to SDTM when rows in the dataset are created from a single SDTM domain. This may be missing for derived rows. \n For SubClass ADVERSE EVENT, use AESEQ, copied from SDTM AE.AESEQ. | Row Identifier | 1 | OCCDS | ||
| SRCDOM | Source Data | Char | Perm | Identifies the name of the domain or dataset that is the source for this row. If the source data is a supplemental qualifier in SDTM, this variable will contain the value of RDOMAIN in SUPP-- or SUPPQUAL. Used when rows in the OCCDS dataset are from multiple SDTM domains or from one or more ADaM datasets. Not to be used in conjunction with --SEQ. This may be missing for derived rows. \n For SubClass ADVERSE EVENT, AESEQ is used rather than SRCDOM and SRCSEQ. | Row Identifier | 2 | OCCDS | ||
| SRCSEQ | Source Sequence Number | Num | Perm | Identifies the sequence number that is the source for this row. If SRCDOM is a SUPPQUAL, then this variable will contain the sequence number of the relevant related domain record. Used when rows in the OCCDS dataset are from multiple SDTM domains or from one or more ADaM datasets. Not to be used in conjunction with --SEQ. This may be missing for derived rows. \n For SubClass ADVERSE EVENT, AESEQ is used rather than SRCDOM and SRCSEQ. | Row Identifier | 3 | OCCDS | ||
| ASEQ | Analysis Sequence Number | Num | Perm | Sequence number given to ensure uniqueness of subject records within an ADaM dataset. \n ASEQ is useful for traceability when the OCCDS dataset is used as input to another ADaM dataset and the --SEQ variable is not included or unique. ASEQ is described in more detail in ADaMIG v1.2, Section 3.3.1, Identifier Variables for BDS Datasets. | Row Identifier | 4 | OCCDS | ||
| --TERM | Reported Term | Char | Req | Copied from XX.--TERM \n This variable label differs depending on the SDTM domain. See SDTM v1.7 Section 2.2.2, The Events Observation Class, and SDTMIG v3.3 Section 6.2, Models for Events Domains, for details. Required for adverse event data. | MedDRA Dictionary Coding | 1 | OCCDS | ||
| --DECOD | Dictionary-Derived Term | Char | MedDRA | Cond | Copied from XX.--DECOD \n This variable is typically one of the primary variables used in an analysis and would be brought in from the SDTM domain. Equivalent to the MedDRA PT. All other SDTM domain variables and supplemental qualifiers needed for analysis or traceability should also be included. Include the dictionary version in the metadata. \n Conditional on whether coded and used for analysis. Required for adverse event data. | MedDRA Dictionary Coding | 2 | OCCDS | |
| --BODSYS | Body System or Organ Class | Char | MedDRA | Cond | Copied from XX.--BODSYS \n Include the dictionary version in the metadata. \n Conditional on whether coded and used for analysis. Required for adverse event data. | MedDRA Dictionary Coding | 3 | OCCDS | |
| --BDSYCD | Body System or Organ Class Code | Num | MedDRA | Perm | Copied from XX.--BDSYCD or the supplemental qualifier \n This would be copied from the SDTM domain XX or supplemental qualifier dataset. Include the dictionary version in the metadata. \n Required for adverse event data. | MedDRA Dictionary Coding | 4 | OCCDS | |
| --LLT | Lowest Level Term | Char | MedDRA | Cond | Copied from XX.-- LLT or the supplemental qualifier \n Include the dictionary version in the metadata. \n Conditional on whether coded and used for analysis. Required for adverse event data. | MedDRA Dictionary Coding | 5 | OCCDS | |
| --LLTCD | Lowest Level Term Code | Num | MedDRA | Perm | Copied from XX.--LLTCD or the supplemental qualifier \n Include the dictionary version in the metadata. Required for adverse event data. | MedDRA Dictionary Coding | 6 | OCCDS | |
| --PTCD | Preferred Term Code | Num | MedDRA | Perm | Copied from XX.--PTCD or the supplemental qualifier \n Include the dictionary version in the metadata. Required for adverse event data. | MedDRA Dictionary Coding | 7 | OCCDS | |
| --HLT | High Level Term | Char | MedDRA | Cond | Copied from XX.--HLT or the supplemental qualifier \n Include the dictionary version in the metadata. \n Conditional on whether used for analysis. Required for adverse event data. | MedDRA Dictionary Coding | 8 | OCCDS | |
| --HLTCD | High Level Term Code | Num | MedDRA | Perm | Copied from XX.--HLTCD or the supplemental qualifier \n Include the dictionary version in the metadata. Required for adverse event data. | MedDRA Dictionary Coding | 9 | OCCDS | |
| --HLGT | High Level Group Term | Char | MedDRA | Cond | Copied from XX.--HLGT or the supplemental qualifier \n Include the dictionary version in the metadata. \n Conditional on whether used for analysis. Required for adverse event data. | MedDRA Dictionary Coding | 10 | OCCDS | |
| --HLGTCD | High Level Group Term Code | Num | MedDRA | Perm | Copied from XX.--HLGTCD or the supplemental qualifier \n Include the dictionary version in the metadata. Required for adverse event data. | MedDRA Dictionary Coding | 11 | OCCDS | |
| --SOC | Primary System Organ Class | Char | MedDRA | Cond | Copied from XX.--SOC or the supplemental qualifier \n Include the dictionary version in the metadata. \n Conditional on whether a secondary SOC was used for analysis. Required for adverse event data. | MedDRA Dictionary Coding | 12 | OCCDS | |
| --SOCCD | Primary System Organ Class Code | Num | MedDRA | Perm | Copied from XX.--SOCCD or the supplemental qualifier \n Include the dictionary version in the metadata. Required for adverse event data. | MedDRA Dictionary Coding | 13 | OCCDS | |
| --CAT | Category | Char | Perm | Copied from XX.--CAT \n This variable label differs depending on the SDTM domain. | Other Categorization | 1 | OCCDS | ||
| --SCAT | Subcategory | Char | Perm | Copied from XX.--SCAT \n This variable label differs depending on the SDTM domain. | Other Categorization | 2 | OCCDS | ||
| ACATy | Analysis Category y | Char | Perm | Category used in analysis. May be derived from --CAT and/or --SCAT. Examples include records of special interest like prohibited medications, concomitant medications taken during an infusion reaction, growth factors, antimicrobial medications, and other such categories not defined elsewhere or present in SDTM domains. | Other Categorization | 3 | OCCDS | ||
| CMTRT | Reported Name of Drug, Med, or Therapy | Char | Req | CM.CMTRT | WHO Drug Dictionary Coding | 1 | OCCDS | ||
| CMDECOD | Standardized Medication Name | Char | WHO Drug | Cond | CM.CMDECOD \n This is typically one of the primary variables used in CM analysis and would be copied from the SDTM CM domain. Include the dictionary version in the variable metadata. \n Conditional on whether coded and used for analysis. | WHO Drug Dictionary Coding | 2 | OCCDS | |
| CMCLAS | Medication Class | Char | Perm | CM.CMCLAS \n Include the dictionary version in the metadata. | WHO Drug Dictionary Coding | 3 | OCCDS | ||
| CMCLASCD | Medication Class Code | Char | Perm | CM.CMCLASCD \n Include the dictionary version in the metadata. | WHO Drug Dictionary Coding | 4 | OCCDS | ||
| ATCy | ATC Level y Text | Char | WHO Drug | Cond | Corresponds to the ATC Level Text for WHO Drug. Include the dictionary version in the variable metadata. \n Conditional, based on analysis at multiple levels (y) | WHO Drug Dictionary Coding | 5 | OCCDS | |
| ATCyCD | ATC Level y Code | Char | WHO Drug | Cond | Corresponds to the ATC Level Code for WHO Drug. Include the dictionary version in the variable metadata. \n Conditional, based on analysis at multiple levels (y) | WHO Drug Dictionary Coding | 6 | OCCDS | |
| --STDTC | Start Date/Time of Observation | Char | ISO 8601 datetime or interval | Cond | Copied from XX.–STDTC \n Conditional on whether start date is pertinent for study and is populated in SDTM \n This variable label differs depending on the SDTM domain. AESTDTC is required for adverse event data. | Timing | 1 | OCCDS | |
| ASTDT | Analysis Start Date | Num | Cond | Created from converting XX.--STDTC from character ISO 8601 format to numeric date format, applying imputation rules if specified in the statistical analysis plan (SAP) or metadata \n Conditional on whether start date is pertinent for study and is populated in SDTM. Required for adverse event data. | Timing | 2 | OCCDS | ||
| ASTTM | Analysis Start Time | Num | Cond | Created from converting XX.--STDTC from character ISO 8601 format to numeric time format, applying imputation rules if specified in the SAP or metadata \n Conditional on whether start time is pertinent for study and is populated in SDTM | Timing | 3 | OCCDS | ||
| ASTDTM | Analysis Start Datetime | Num | Cond | Created from converting XX.--STDTC from character ISO 8601 format to numeric datetime format, applying imputation rules if specified in the SAP or metadata \n Conditional on whether start datetime is pertinent for study and is populated in SDTM | Timing | 4 | OCCDS | ||
| ASTDTF | Analysis Start Date Imputation Flag | Char | (DATEFL) | Cond | The level of imputation of analysis start date. Imputation flags are described in ADaMIG v1.2 Section 3.1.3, Date and Time Imputation Flag Variables. \n Conditional on whether ASTDT (or the date part of ASTDTM) was imputed | Timing | 5 | OCCDS | |
| ASTTMF | Analysis Start Time Imputation Flag | Char | (TIMEFL) | Cond | The level of imputation of analysis start time. Imputation flags are described in ADaMIG v1.2 Section 3.1.3, Date and Time Imputation Flag Variables. \n Conditional on whether ASTTM (or the time part of ASTDTM) was imputed | Timing | 6 | OCCDS | |
| --ENDTC | End Date/Time of Observation | Char | ISO 8601 datetime or interval | Cond | Copied from XX.--ENDTC \n Conditional on whether end date is pertinent for study and is populated in SDTM \n This variable label differs depending on the SDTM domain. AEENDTC is required for adverse event data. | Timing | 7 | OCCDS | |
| AENDT | Analysis End Date | Num | Cond | Created from converting XX.--ENDTC from character ISO 8601 format to numeric date format, applying imputation rules if specified in the SAP or metadata. If both ASTDT and AENDT are populated then ASTDT must less than or equal to AENDT. \n Conditional on whether end date is pertinent for study and is populated in SDTM. Required for adverse event data. | Timing | 8 | OCCDS | ||
| AENTM | Analysis End Time | Num | Cond | Created from converting XX.--ENDTC from character ISO 8601 format to numeric time format, applying imputation rules if specified in the SAP or metadata \n Conditional on whether end time is pertinent for study and is populated in SDTM | Timing | 9 | OCCDS | ||
| AENDTM | Analysis End Datetime | Num | Cond | Created from converting XX.--ENDTC from character ISO 8601 format to numeric datetime format, applying imputation rules if specified in the SAP or metadata. If both ASTDTM and AENDTM are populated then ASTDTM must less than or equal to AENDTM. \n Conditional on whether end datetime is pertinent for study and is populated in SDTM | Timing | 10 | OCCDS | ||
| AENDTF | Analysis End Date Imputation Flag | Char | (DATEFL) | Cond | The level of imputation of analysis end date. Imputation flags are described in Section 2.9.3.3, Date and Time Imputation Flag Variables. \n Conditional on whether AENDT (or the date part of AENDTM) was imputed | Timing | 11 | OCCDS | |
| AENTMF | Analysis End Time Imputation Flag | Char | (TIMEFL) | Cond | The level of imputation of analysis end time. Imputation flags are described in Section 2.9.3.3, Date and Time Imputation Flag Variables. \n Conditional on whether AENTM (or the date part of AENDTM) was imputed | Timing | 12 | OCCDS | |
| ASTDY | Analysis Start Relative Day | Num | Cond | The number of days from an anchor date (not necessarily DM.RFSTDTC) to ASTDT \n Example derivation: \n ASTDT - ADSL.TRTSDT + 1 if ASTDT >= ADSL.TRTSDT, else ASTDT - ADSL.TRTSDT if ASTDT< ADSL.TRTSDT \n This variable may instead be copied from --STDY. \n Conditional on whether analysis start relative day is pertinent to the study. Required for adverse event data. | Timing | 13 | OCCDS | ||
| --STDY | Study Day of Start of Observation* | Num | Perm | Copied from XX.--STDY \n ASTDY may differ from --STDY due to date imputation and the option in ADaM to use a reference date other than SDTM's RFSTDTC. Including XX.--STDY in addition to ASTDY adds traceability. \n For SubClass ADVERSE EVENT, conditional on whether the AESTDY variable is in the SDTM AE dataset | Timing | 14 | OCCDS | ||
| AENDY | Analysis End Relative Day | Num | Perm | The number of days from an anchor date (not necessarily DM.RFSTDTC) to AENDT \n Example derivation: \n AENDT - ADSL.TRTSDT + 1 if AENDT >= ADSL.TRTSDT, else AENDT - ADSL.TRTSDT if AENDT < ADSL.TRTSDT \n This variable may instead be copied from --ENDY. \n If both ASTDY and AENDY are populated then ASTDY must be less than or equal to AENDY. Required for adverse event data. | Timing | 15 | OCCDS | ||
| --ENDY | Study Day of End of Observation* | Num | Perm | Copied from XX.--ENDY \n AENDY may differ from --ENDY due to date imputation and the option in ADaM to use a reference date other than SDTM's RFSTDTC. Including XX.--ENDY in addition to AENDY adds traceability. \n If both --STDY and --ENDY are populated then --STDY must be less than or equal to --ENDY \n For SubClass ADVERSE EVENT, conditional on whether the AEENDY variable is in the SDTM AE dataset | Timing | 16 | OCCDS | ||
| ADURN | Analysis Duration (N) | Num | Perm | Derive from ASTDT (or ASTDTM) and AENDT (or AENDTM). | Timing | 17 | OCCDS | ||
| ADURU | Analysis Duration Units | Char | (UNIT) | Cond | Conditional on whether ADURN is included | Timing | 18 | OCCDS | |
| --DUR | Duration of XX | Char | ISO 8601 duration | Cond | Copied from XX.--DUR \n Because --DUR is a collected field and ADURN is derived, the values will often differ. Including XX.--DUR in addition to ADURN adds traceability. \n For SubClass ADVERSE EVENT, conditional on whether the AEDUR variable is in the SDTM AE dataset. | Timing | 19 | OCCDS | |
| APERIOD | Period | Num | Perm | 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 variables. See Section 2.9.6.3, Timing Variables for BDS Datasets, for more information on this variable. | Timing | 20 | OCCDS | ||
| APERIODC | Period (C) | Char | Perm | Text characterizing to which period the record belongs. One-to-one map to APERIOD. | Timing | 21 | OCCDS | ||
| APHASE | Phase | Char | Perm | 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 PRODUCT, and FOLLOW-UP. | Timing | 22 | OCCDS | ||
| PREFL | Pre-product Flag | Char | Y | Cond | Character indicator of whether the observation occurred before the subject started product \n Example derivation: \n If ASTDT < ADSL.TRTSDT then PREFL="Y" \n This variable is conditional on whether the concept of pre-product is a feature of the study and used in analysis. | Adverse Events and Concomitant Medications Indicator | 1 | OCCDS | |
| FUPFL | Follow-up Flag | Char | Y | Cond | Character indicator of whether the observation occurred while the subject was on follow-up \n Example derivation: \n If ASTDT > ADSL.TRTEDT then FUPFL="Y" \n This variable is conditional on whether the concept of follow-up is a feature of the study and used in analysis. | Adverse Events and Concomitant Medications Indicator | 2 | OCCDS | |
| TRTEMFL | Product Emergent Analysis Flag | Char | Y | Cond | Product-emergent flag as defined for analysis Example derivation: \n If ADSL.TRTSDT<=ASTDT<=ADSL.TRTEDT + x days then TRTEMFL="Y" \n The number x in this derivation is defined by the producer and often incorporates the known half-life of the drug. \n For datasets other than SubClass ADVERSE EVENT, this variable is conditional on whether the concept of product emergent is a key feature of the analysis. | Adverse Events Indicator | 1 | OCCDS | |
| TREMxxFL | Product Emergent Period xx Flag | Char | Y | Cond | This variable is required if there are multiple periods where product emergence is a key feature of the analysis for each period. \n If TREMxxFL is included, TRTEMFL is defined as the overall product- emergent flag. | Adverse Events Indicator | 2 | OCCDS | |
| TRTEMwFL | Product Emergent Analysis w Flag | Char | Y | Perm | This variable is used if there are other analysis needs (e.g., different cut-offs) where product emergence is a key feature of the analysis. \n If TREMwFL is included, TRTEMFL is defined as the overall product-emergent flag. | Adverse Events Indicator | 3 | OCCDS | |
| AETRTEM | Product Emergent Flag | Char | (NY) | Perm | Product-emergent flag from SDTM, if available. \n Derivation: \n SUPPAE.QVAL where QNAM="AETRTEM" \n TRTEMFL may differ from AETRTEM due to different definitions, date imputation, and other analysis rules. Including AETRTEM in addition to TRTEMFL will add traceability. \n For SubClass ADVERSE EVENT, conditional on whether the AETRTEM variable is in the SDTM AE dataset and populated. | Adverse Events Indicator | 4 | OCCDS | |
| ONTRTFL | On Product Record Flag | Char | Y | Cond | Character indicator of whether the observation occurred while the subject was on product. A codelist of Y, N, null may be used as described in ADaMIG Section 3.3.8, Indicator Variables for BDS Datasets. \n Example derivation: \n If ADSL.TRTSDT <= ASTDT <= ADSL.TRTEDT then ONTRTFL = "Y" \n This variable is conditional on whether the concept of on product is a feature of the study and used in analysis. | Concomitant Medications Indicator | 1 | OCCDS | |
| ONTRxxFL | On Product Period xx Flag | Char | Y | Perm | This variable is used if there are multiple periods where on product is a key feature of the analysis for each period. \n If ONTRxxFL is included, ONTRTFL is defined as the overall on-product flag. | Concomitant Medications Indicator | 2 | OCCDS | |
| ONTRTwFL | On Product Record w Flag | Char | Y | Perm | This variable is used if there are other analysis needs (e.g., different cut-offs) where on product is a key feature of the analysis. \n If ONTRTwFL is included, ONTRTFL is defined as the overall on-product flag. | Concomitant Medications Indicator | 3 | OCCDS | |
| ANLzzFL | Analysis Flag zz | Char | Y | Cond | The ANLzzFL flag is useful in many circumstances; an example is when more than 1 coding path is included for analysis, in which case separate analysis flags could be used to denote primary coding path or the records used for analysis from each coding path. A codelist of Y, N, null may be used as described in ADaMIG v1.2 Section 3.3.8, Indicator Variables for BDS Datasets. \n This variable is conditional on whether analysis records flags are needed for analysis. | Indicator | 1 | OCCDS | |
| --OCCUR | XX Occurrence | Char | (NY) | Cond | Copied from XX.--OCCUR \n Conditional on whether this content is pertinent for analysis and is populated in SDTM \n SDTM does not allow variable AEOCCUR, so this variable is not available to include in ADaM. | SDTM Indicator | 1 | OCCDS | |
| --PRESP | XX Pre-Specified | Char | (NY) | Cond | Copied from XX.--PRESP \n Conditional on whether this content is pertinent for analysis and is populated in SDTM | SDTM Indicator | 2 | OCCDS | |
| AOCCSFL | 1st Occurrence of SOC Flag | Char | Y | Perm | Character indicator for the first occurrence of the system organ class within the subject \n Example derivation: Sort the data in the required order and flag the first product-emergent record for each body system for each subject. | MedDRA Occurrence Flag | 1 | OCCDS | |
| AOCCSIFL | 1st Max Sev./Int. Occur Within SOC Flag | Char | Y | Perm | Character indicator for the first occurrence of the maximum severity/intensity within the subject and system organ class \n Example derivation: Sort the data in the required order and flag the first product-emergent record for maximum severity within body system for each subject. | MedDRA Occurrence Flag | 2 | OCCDS | |
| AOCCFL | 1st Occurrence within Subject Flag | Char | Y | Perm | Character indicator for the first occurrence of any event/intervention/finding within the subject \n Example derivation: Sort the data in the required order and flag the first product emergent record for each subject. | Occurrence Flag | 1 | OCCDS | |
| AOCCPFL | 1st Occurrence of Preferred Term Flag | Char | Y | Perm | Character indicator for the first occurrence of the preferred term within the subject \n Example derivation: Sort the data in the required order and flag the first product emergent record for each --DECOD for each subject. | Occurrence Flag | 2 | OCCDS | |
| AOCCIFL | 1st Max Sev./Int. Occurrence Flag | Char | Y | Perm | Character indicator for the first occurrence of the event/intervention/finding with the maximum severity/intensity within the subject \n Example derivation: Sort the data in the required order and flag the first product emergent record for maximum severity for each subject. | Occurrence Flag | 3 | OCCDS | |
| AOCCPIFL | 1st Max Sev./Int. Occur Within PT Flag | Char | Y | Perm | Character indicator for the first occurrence of the maximum severity/intensity within the subject and preferred term \n Example derivation: Sort the data in the required order and flag the first product emergent record for maximum severity within preferred term for each subject. | Occurrence Flag | 4 | OCCDS | |
| AOCCzzFL | 1st Occurrence of ... | Char | Y | Perm | Additional flag variables as needed for analysis. Derivation rules for these flags need to be described in the metadata. | Occurrence Flag | 5 | OCCDS | |
| DOSEON | Product Dose at Record Start | Num | Perm | Dose received at the point in time of the record start date Example derivation: \n Obtained from EX.EXDOSE where --STDTC falls between the values of EX.EXSTDTC and EX.EXENDTC | Product/Dose | 1 | OCCDS | ||
| DOSCUMA | Cumulative \n Actual Product Dose | Num | Perm | Cumulative actual study drug dosage at the point in time of the record start date | Product/Dose | 2 | OCCDS | ||
| DOSEU | Product Dose Units | Char | (UNIT) | Cond | Conditional on whether DOSEON and/or DOSCUMA are included. | Product/Dose | 3 | OCCDS | |
| --SER | Serious Event | Char | (NY) | Perm | XX.–SER AESER is equired for adverse event data. | Adverse Event Descriptive | 1 | OCCDS | |
| --SEV | Severity/Intensity | Char | (AESEV) or (SEVRS) | Perm | XX.--SEV \n For SubClass ADVERSE EVENT, conditional on whether the --SEV variable is in the SDTM AE dataset. Note that either --SEV or --TOXGR should be included in SDTM. | Adverse Event Descriptive | 2 | OCCDS | |
| --SEVN | Severity/Intensity (N) | Num | 1, 2, 3 | Perm | Code XX.--SEV to numeric \n Low intensity should correspond to low value | Adverse Event Descriptive | 3 | OCCDS | |
| ASEV | Analysis Severity/Intensity | Char | Perm | Apply imputation rules for missing severity of adverse events as specified in the \n SAP or metadata. May change case of text, such as from all uppercase in --SEV to mixed case in ASEV. | Adverse Event Descriptive | 4 | OCCDS | ||
| ASEVN | Analysis Severity/Intensity (N) | Num | 1, 2, 3 | Perm | Code ASEV to numeric \n Low intensity should correspond to low value | Adverse Event Descriptive | 5 | OCCDS | |
| SEVGRy | Pooled Severity Group y | Char | Perm | Pooled grouping of AE severity for analysis (e.g., mild/moderate, severe) | Adverse Event Descriptive | 6 | OCCDS | ||
| SEVGRyN | Pooled Severity Group y (N) | Num | Perm | Code SEVGRy to numeric \n Low intensity should correspond to low value | Adverse Event Descriptive | 7 | OCCDS | ||
| --REL | Causality | Char | Perm | XX.--REL | Adverse Event Descriptive | 8 | OCCDS | ||
| --RELN | Causality (N) | Num | Perm | Code XX.--REL to numeric \n Low relation should correspond to low value | Adverse Event Descriptive | 9 | OCCDS | ||
| AREL | Analysis Causality | Char | Perm | Apply imputation rules for missing causality of study drug as specified in the SAP or metadata. May change case of text, such as from all uppercase in --REL to mixed case in AREL. | Adverse Event Descriptive | 10 | OCCDS | ||
| ARELN | Analysis Causality (N) | Num | Perm | Code AREL to numeric | Adverse Event Descriptive | 11 | OCCDS | ||
| RELGRy | Pooled Causality Group y | Char | Perm | Pooled grouping of causality of study drug for analysis (e.g. related, not related) | Adverse Event Descriptive | 12 | OCCDS | ||
| RELGRyN | Pooled Causality Group y (N) | Num | Perm | Code of RELGRy to numeric \n Low relation should correspond to low value | Adverse Event Descriptive | 13 | OCCDS | ||
| --TOXGR | Standard Toxicity Grade | Char | Perm | XX.--TOXGR \n For SubClass ADVERSE EVENT, conditional on whether the --TOXGR variable is in the SDTM AE dataset. Note that either --SEV or --TOXGR should be included in SDTM. | Adverse Event Descriptive | 14 | OCCDS | ||
| --TOXGRN | Standard Toxicity Grade (N) | Num | Perm | Code --TOXGR to numeric \n Low toxicity should correspond to low value | Adverse Event Descriptive | 15 | OCCDS | ||
| ATOXGR | Analysis Toxicity Grade | Char | Perm | Toxicity grade for analysis. May be based on --TOXGR or an imputed or assigned value. May change case of text, such as from all uppercase in --TOXGR to mixed \n case in ATOXGR. | Adverse Event Descriptive | 16 | OCCDS | ||
| ATOXGRN | Analysis Toxicity Grade (N) | Num | Perm | Code ATOXGR to numeric \n Low toxicity should correspond to low value | Adverse Event Descriptive | 17 | OCCDS | ||
| TOXGGRy | Pooled Toxicity Grade Group y | Char | Perm | Pooled grouping of toxicity grade for analysis | Adverse Event Descriptive | 18 | OCCDS | ||
| TOXGGRyN | Pooled Toxicity Grade Group y (N) | Num | Perm | Code of TOXGGRy to numeric \n Low toxicity should correspond to low value | Adverse Event Descriptive | 19 | OCCDS | ||
| --ACN | Action Taken with Study Product | Char | (TPACN) | Perm | XX.--ACN \n Required if XX.--ACN is present and populated | Adverse Event Descriptive | 20 | OCCDS | |
| --STAT | Completion Status | Char | Perm | XX.--STAT | Concomitant Medications Descriptive | 1 | OCCDS | ||
| --INDC | Indication | Char | Perm | XX.--INDC | Concomitant Medications Descriptive | 2 | OCCDS | ||
| --DOSE | Dose per Administration | Num | Perm | XX.--DOSE | Concomitant Medications Descriptive | 3 | OCCDS | ||
| --DOSFRM | Dose Form | Char | Perm | XX.--DOSFRM | Concomitant Medications Descriptive | 4 | OCCDS | ||
| --DOSRGM | Intended Dose Regimen | Char | Perm | XX.--DOSRGM | Concomitant Medications Descriptive | 5 | OCCDS | ||
| --ROUTE | Route of Administration | Char | Perm | XX.--ROUTE | Concomitant Medications Descriptive | 6 | OCCDS | ||
| SMQzzNAM | SMQ zz Name | Char | Cond | The Standardized MedDRA query name. Would be blank for terms that are not in the SMQ. Therefore this variable could be blank for all records if no terms within the study were included in the SMQ. \n Conditional on whether SMQ analysis is done | Standardized MedDRA Query | 1 | OCCDS | ||
| SMQzzCD | SMQ zz Code | Num | Perm | The SMQ number code | Standardized MedDRA Query | 2 | OCCDS | ||
| SMQzzSC | SMQ zz Scope | Char | BROAD, NARROW | Cond | The search strategy for SMQs can be narrow or broad. The preferred terms that are narrow in scope have high specificity for identifying events of interest, whereas the broad terms have high sensitivity. By definition, all narrow terms are also considered within the broad scope. Therefore, to summarize all broad terms, terms with either narrow or broad would be considered. Will be null for terms that do not meet the criteria. \n Conditional on whether SMQ analysis is done | Standardized MedDRA Query | 3 | OCCDS | |
| SMQzzSCN | SMQ zz Scope (N) | Num | 1, 2 | Perm | Will be null for terms that do not meet the criteria | Standardized MedDRA Query | 4 | OCCDS | |
| CQzzNAM | Customized Query zz Name | Char | Cond | The CQ name or name of the adverse event of special interest category based on a grouping of terms. Would be blank for terms that are not in the CQ. \n Conditional on whether CQ analysis is done \n Examples: "DERMATOLOGICAL EVENTS" "CARDIAC EVENTS", "IARS (INFUSION ASSOCIATED REACTIONS)" | Standardized MedDRA Query | 5 | OCCDS | ||
| ADECODy | Analysis Dictionary-Derived Term y | Char | Perm | The terms used for the analysis when combining multiple CQs or multiple SMQs and the original MedDRA terms under 1 variable \n Although designed for MedDRA queries, this variable could be used for other OCCDS analysis needs. | Standardized MedDRA Query | 6 | OCCDS | ||
| DECDORGw | PT in Original Dictionary w | Char | MedDRAw | Perm | Original preferred term coding of XX.--TERM using MedDRA or other dictionary version X.X | Original or Prior MedDRA Coding | 1 | OCCDS | |
| BDSYORGw | SOC in Original Dictionary w | Char | MedDRAw | Perm | Original body system coding of XX.--TERM using MedDRA or other dictionary version X.X | Original or Prior MedDRA Coding | 2 | OCCDS | |
| HLGTORGw | HLGT in Original Dictionary w | Char | MedDRAw | Perm | Original HLGT coding of XX.--TERM using MedDRA or other dictionary version X.X | Original or Prior MedDRA Coding | 3 | OCCDS | |
| HLTORGw | HLT in Original Dictionary w | Char | MedDRAw | Perm | Original HLT coding of XX.--TERM using MedDRA or other dictionary version X.X | Original or Prior MedDRA Coding | 4 | OCCDS | |
| LLTORGw | LLT in Original Dictionary w | Char | MedDRAw | Perm | Original LLT coding of XX.--TERM using MedDRA or other dictionary version X.X | Original or Prior MedDRA Coding | 5 | OCCDS | |
| LLTNORGw | LLT Code in Original Dictionary w | Char | MedDRAw | Perm | Original LLT code of XX.--TERM using MedDRA or other dictionary version X.X | Original or Prior MedDRA Coding | 6 | OCCDS | |
| DECDORGw | Standardized Med Name in Orig Dict w | Char | WHODRUGw | Perm | Original standardized medication name of CM.CMTRT using WHO Drug version X.X | Original or Prior WHO Drug Coding | 1 | OCCDS | |
| CLASORGw | Medication Class in Orig Dictionary w | Char | WHODRUGw | Perm | Original medication class of CM.CMTRT using WHO Drug version X.X | Original or Prior WHO Drug Coding | 2 | OCCDS | |
| CLCDORGw | Medication Class Code in Orig Dict w | Char | WHODRUGw | Perm | Original medication class code of CM.CMTRT using WHO Drug version X.X | Original or Prior WHO Drug Coding | 3 | OCCDS | |
| ATyCORGw | ATC Level y Code in Orig Dictionary w | Char | WHODRUGw | Perm | Original ATC Level y code of CM.CMTRT using WHO Drug version X.X | Original or Prior WHO Drug Coding | 4 | OCCDS | |
| ATyTORGw | ATC Level y Text in Orig Dictionary w | Char | WHODRUGw | Perm | Original ATC Level y text of CM.CMTRT using WHO Drug version X.X | Original or Prior WHO Drug Coding | 5 | OCCDS | |
| STRTMy | Stratum y | Char | Req | Indicates stratification factors used when calculating the value of the input parameter. At least one STRTMy column must be present and populated. | Reference | 1 | REFERENDS | ||
| STRVALy | Stratum y Value | Char | Req | Identifies the stratum with which the input parameter is associated. At least one STRVALy column must be present and populated. | Reference | 2 | REFERENDS | ||
| INPRM | Input Parameter | Char | Req | Indicate the calculated input parameter for the stratum or strata. | Reference | 3 | REFERENDS | ||
| INPRMVAL | Input Parameter Value | Num | Req | This is the value of the input parameter. | Reference | 4 | REFERENDS | ||
| INPRMU | Input Parameter Unit | Char | Perm | Unit associated with the input parameter value. | Reference | 5 | REFERENDS | ||
| REFSRCE | Reference Data Source | Char | Perm | Information identifying the source of the reference data - this may be captured in the dataset or in the define file | Reference | 6 | REFERENDS |
Overview
Content Tools