You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Variable NameVariable LabelTypeCodelist/Controlled TermsCoreNotes

STUDYID

Study IdentifierChar
ReqDM.STUDYID, ADSL STUDYID, and/or STUDYID from another ADaM or SDTM dataset appropriate to the analysis.
USUBJIDUnique Subject IdentifierChar
ReqDM.USUBJID, ADSL.USUBJID, and/or USUBJID from another ADaM or SDTM dataset appropriate to the analysis.
SUBJIDSubject Identifier for the StudyChar
PermDM.SUBJID, ADSL.SUBJID, and/or SUBJID from another ADaM dataset appropriate to the analysis. SUBJID is required in ADSL, but permissible in other datasets.
SITEIDStudy Site IdentifierChar
PermDM.SITEID, ADSL.SITEID, and/or SITEID from another ADaM dataset appropriate to the analysis. SITEID is required in ADSL, but permissible in other datasets.
TRTPPlanned TreatmentChar
CondTRTP is a record-level identifier that represents the planned treatment attributed to a record for analysis purposes. TRTP indicates how treatment varies by record within a subject and enables analysis of crossover and other designs. Though there is no requirement that TRTP will correspond to the TRTxxP as defined by the record's value of APERIOD, if populated, TRTP must match at least one value of the character planned treatment variables in ADSL (e.g., TRTxxP, TRTSEQP, TRxxPGy).
As noted previously, at least one treatment variable is required even in non-randomized trials. This requirement is satisfied by any subject-level or record-level treatment variables (e.g., TRTxxP, TRTP, TRTA). Even if not used for analysis, any ADSL treatment variable may be included in the BDS dataset.
TRT01PPlanned Treatment for Period 01Char
Cond
TRTAActual TreatmentChar
CondTRTA is a record-level identifier that represents the actual treatment attributed to a record for analysis purposes. TRTA indicates how treatment varies by record within a subject and enables analysis of crossover and other multi-period designs. Though there is no requirement that TRTA will correspond to the TRTxxA as defined by the record's value of APERIOD, TRTA must match at least one value of the character actual treatment variables in ADSL (e.g., TRTxxA, TRTSEQA, TRxxAGy).
As noted previously, at least one treatment variable is required. This requirement is satisfied by any subject-
TRT01AActual Treatment for Period 01Char
Cond
ADTAnalysis DateNum
PermThe date associated with AVAL and/or AVALC in numeric format.
ADTMAnalysis Datetime

Num



PermThe datetime associated with AVAL and/or AVALC in numeric format.
ADYAnalysis Relative DayNum
PermThe relative day of AVAL and/or AVALC. The number of days from an anchor date (not necessarily DM.RFSTDTC) to ADT.
AVISITAnalysis VisitChar
CondThe 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 ADaMIG v1.2 Section 3.3.8, Indicator Variables for BDS Datasets, for information about flag variables. AVISIT should be unique for a given analysis visit window. In the event that a record does not fall within any predefined analysis timepoint window, AVISIT can be populated in any way that the producer chooses to indicate this fact (e.g., blank or "Not Windowed"). The way that AVISIT is calculated, including the variables used in its derivation, should be indicated in the variable metadata for AVISIT. The values and the rules for deriving AVISIT may be different for different parameters within the same dataset. Values of AVISIT are producer-defined, and are often directly usable in Clinical Study Report displays.
AVISITNAnalysis Visit (N)Num
PermNumeric 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.
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.
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.
ATPTAnalysis TimepointChar
CondThe 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.
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). 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.
APHASEPhaseChar
PermAPHASE is a categorization of timing within a study, for example a higher-level categorization of APERIOD or an analysis epoch. For example, APHASE could describe spans of time for SCREENING, ON TREATMENT, and FOLLOW-UP. APHASE may be used alone or in addition to APERIOD. APHASE is independent of TRTxxP within ADSL. APHASE may be populated for spans of time where a subject is not on treatment. The value of APHASE (if populated) must be one of the values found in the ADSL APHASEw variables.
APERIODPeriodNum
CondAPERIOD 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
PARAMParameterChar
ReqThe description of the analysis parameter. PARAM must include all descriptive and qualifying information relevant to the analysis purpose of the parameter.
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.
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.
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.
PARAM is often directly usable in Clinical Study Report displays. Note that in the ADaMIG, "parameter" is a synonym of "analysis parameter."
PARAM must be present and populated on every record in a BDS dataset.
PARAMCDParameter Codetext
ReqThe 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 ADaMIG v1.2 Section 3.1.1, General Variable Conventions. There must be a one-to-one relationship between PARAM and PARAMCD within a dataset.
PARAMCD must be present and populated on every record in a BDS dataset.
PARAMNParameter (N)Num
PermNumeric 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.
if PARAMN is populated on any record for a PARAM, it must be populated on every record for that PARAM.
AVALAnalysis ValueNum
CondNumeric 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.
AVALCAnalysis Value (C)Char
CondCharacter 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.
AVALC is required if AVAL is not present, since either AVAL or AVALC must be present in the dataset.
BASEBaseline ValueNum
CondThe 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.
CHGChange from BaselineNum
PermChange 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.
PCHGPercent Change from BaselineNum
PermPercent 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.
CRITyAnalysis Criterion yChar
PermA 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.
CRITyFLCriterion y Evaluation Result FlagChar
CondCharacter 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.
DTYPEDerivation TypeChar(DTYPE)CondAnalysis 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. Three common situations when DTYPE should be populated:
• A new row is added within a parameter with the analysis value populated based on other rows within the parameter.
• A new row is added within a parameter with the analysis value populated based on a constant value or data from other subjects.
• An analysis value (AVAL or AVALC) on an existing record is being replaced with a value based on a pre-specified algorithm.
DTYPE is used to denote analysis values that are "special cases" within a parameter. For each value of DTYPE, the precise derivation algorithm must be defined in analysis variable metadata, even for DTYPE values in the CDISC Controlled Terminology. The controlled terminology for DTYPE is extensible. See ADAaMIG v1.2 Section 4, Implementation Issues, Standard Solutions, and Examples for examples of the use of DTYPE.
Some examples of DTYPE values:
• LOCF = last observation carried forward.
• WOCF = worst observation carried forward.
• AVERAGE = average of values.
ABLFLBaseline Record FlagCharYCondCharacter indicator to identify the baseline record for each subject, parameter, and baseline type (BASETYPE) combination. See BASETYPE in ADaMIG v1.2 Table 3.3.4.1.1. ABLFL is required if BASE is present in the dataset.
A baseline record may be derived (e.g., it may be an average), in which case DTYPE must also be populated. If BASE is populated for a parameter, and BASE is non-null for a subject for that parameter, then there must be a record flagged by ABLFL for that subject and parameter.
ANLzzFLAnalysis Flag zzCharYCondANLzzFL is a conditionally required flag to be used in addition to other selection variables when the other selection variables in combination are insufficient to identify the exact set of records used for one or more analyses. Often one ANLzzFL will serve to support the accurate selection of records for more than one analysis. Note that it is allowable to add additional descriptive text to the label (see ADaMIG v1.2 Section 3.1.6, Item 1).
When defining the set of records used in a particular analysis or family of analyses, ANLzzFL is supplemental to, and is intended to be used in conjunction with, other selection variables, such as subject-level, parameter-level and record-level population flags, AVISIT, DTYPE, grouping variables such as SITEGRy, and others. The lower-case letter "zz" in the variable name is an index for the zzth record selection algorithm where "zz" is replaced with a zero-padded two-digit integer [01-99]. Every record selection algorithm "zz" (i.e., every algorithm for populating an ANLzzFL) must be defined in variable metadata. When the set of records that the algorithm "zz" operates on is pre-filtered by application of other criteria, such as a record-level population flag, then the selection algorithm definition in the metadata must so specify.
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>."
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.
COUNTRYCountryChar
PermADSL.COUNTRY
AGEAgeNum
PermADSL.AGE
SEXSexChar
PermADSL.SEX
RACERaceChar
PermADSL.RACE
ETHNICEthnicityChar
PermADSL.ETHNIC
SAFFLSafety Population FlagCharY;NCondADSL.SAFFL
RANDFLRandomized Population FlagCharY;NCondADSL.RANDFL
TRTSDTDate of First Exposure to TreatmentNum
PermADSL.TRTSDT
TRTSDTMDatetime of First Exposure to TreatmentNum
PermADSL.TRTSDTM
TRTEDTDate of Last Exposure to TreatmentNum
PermADSL.TRTEDT
TRTEDTMDatetime of Last Exposure to Treatmentinteger
PermADSL.TRTEDTM
LBSEQSequence NumberNum
PermVS.VSSEQ
VISITVisit NameChar
PermVS.VISIT
VISITNUMVisit NumberNum
PermVS.VISITNUM
VSTPTPlanned Time
Point Name
Char
PermVS.VSTPT
VSTPTNUMPlanned Time
Point Number
Char
PermVS.VSTPTNUM
  • No labels