TIG v1.0 ADaM Metadata Staging

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 &quot;special cases&quot; 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