5  Adam Metadata

5.1 ADaM Metadata for Occurrence Data (OCCDS): A Detailed Explanation

Chapter 3 of the “ADaM Structure for Occurrence Data (OCCDS) Implementation Guide v1.1” delves into the critical aspects of metadata within the ADaM (Analysis Data Model) framework, specifically for Occurrence Data Structure (OCCDS). This chapter is essential for understanding how clinical trial data, particularly adverse events, concomitant medications, and medical history, are structured and documented for analysis and regulatory submissions.

—Core Principles of ADaM Metadata—

The guide emphasizes adherence to CDISC (Clinical Data Interchange Standards Consortium) standards, ensuring consistency and clarity in data representation. Key principles include:

Harmonization with SDTM: Variables carried over from SDTM (Study Data Tabulation Model) must maintain their original name, label, values, and meaning in ADaM datasets. This practice ensures data integrity and consistency across different stages of data processing.

• Variable Naming Conventions:

  Standard CDISC practice uses “–” as a placeholder for the two-letter domain prefix in variable names (e.g., --TERM).

  In documentation, “XX” often represents a generic domain name.

  When creating actual metadata, these placeholders must be replaced with the specific two-letter SDTM domain code (e.g., AE for Adverse Events).

• Handling Modified and Unmodified Variables:

• Analysis Variables (Prefix “A”): If an SDTM variable’s content is modified for analysis purposes (e.g., imputing missing data, creating a new derivation), its ADaM counterpart should be prefixed with “A” (e.g., ABODSYS for an analysis version of AEBODSYS). This clearly signals that the variable’s values might differ from the original SDTM variable.

• Unmodified Variables (Prefix “U”): When combining data from multiple SDTM domains into a single variable in ADaM, but without altering the original content, a “U” prefix (for “unmodified”) is used (e.g., UBODSYS if combining AEBODSYS and MHBODSYS). This convention signifies that the variable’s values are directly from the source SDTM variables without any modifications.

5.1.1 Dataset Metadata (Section 3.1)

Dataset metadata provides foundation information about the OCCDS dataset itself.

Data Structure Name and Description: These identify the dataset (e.g., OCCDS for Occurrence Data Structure, ADAE for Adverse Events Analysis Dataset) and provide a concise overview of its content.

Important

Class of Dataset: For OCCDS, the dataset class is consistently OCCURRENCE DATA STRUCTURE.

SubClass of Dataset: Introduced with Define-XML v2.1, this allows for a more granular classification of datasets. A notable subclass is ADVERSE EVENT.

• ADVERSE EVENT SubClass: This specific subclass is designed to standardize the representation of data for typical adverse event analyses.

• Datasets belonging to this subclass must also adhere to all general OCCDS principles outlined in the guide’s purpose section.

The primary SDTM input for this subclass is the AE (Adverse Events) domain, often supplemented by SUPPAE (Supplemental Qualifiers for AE), FA (Findings About), and ADSL (Subject-Level Analysis Dataset).

It’s crucial to note that data from other event domains like Medical History (MH) or Clinical Events (CE) are not part of the ADVERSE EVENT SubClass directly.

Furthermore, not all OCCDS datasets containing adverse event data will automatically be classified under the ADVERSE EVENT SubClass (e.g., an OCCDS dataset combining CE and AE data would not qualify).

• CDISC Notes: These provide additional guidance and context for data producers. . The guide also includes examples of how these metadata elements are structured within Define-XML v2.1 for datasets like ADSL, ADQSADAS, and ADAE

Dataset	Description	Class - SubClass	Structure	Purpose	Keys	Documentation Location
ADSL	Subject-Level Analysis	SUBJECT LEVEL ANALYSIS DATASET	One record per subject	Analysis	STUDYID, USUBJID	Screen Failures are excluded since they are not needed for this study analysis. See referenced dataset creation program and ADRG adsl.sas. Analysis Data Reviewer’s Guide [6]. File: adsl.xpt
ADQSADAS	ADAS-Cog Analysis	BASIC DATA STRUCTURE	One record per subject per parameter per analysis visit per analysis date	Analysis	STUDYID, USUBJID, PARAMCD, AVISIT, ADT	See referenced dataset creation program and ADRG adqsadas.sas. Analysis Data Reviewer’s Guide [Section2.1]. File: adqsadas.xpt
ADAE	Adverse Events Analysis Dataset	OCCURRENCE DATA STRUCTURE - ADVERSE EVENT	One record per subject per adverse event	Analysis	STUDYID, USUBJID, AETERM, ASTDT, AESEQ	See SAS program adae.sas. File: adae.xpt

5.1.2 Variable Metadata (Section 3.2)

Unlike the ADaM Basic Data Structure (BDS) which utilizes PARAM and AVAL variables, OCCDS does not. However, some BDS variables can be incorporated into OCCDS, and some OCCDS-defined variables can be used in non-OCCDS ADaM structures where appropriate.

The guide outlines common variable categories within ADaM OCCDS, recommending the inclusion of all necessary variables from SDTM and their supplemental qualifiers for complete analysis and traceability.

Key variable categories include:

• ADSL Variables: STUDYID,USUBJID,SUBJID,SITEID subject-level variables from the ADSL dataset that are frequently included in OCCDS datasets to provide essential subject demographics and characteristics.

• Identifier Variables: Essential for uniquely identifying records and subjects. Examples include USUBJID (Unique Subject Identifier), STUDYID (Study Identifier), and AESEQ (Sequence Number for Adverse Events). For stacked datasets (combining data from multiple SDTM domains), SRCDOM (Source Domain) and SRCSEQ (Source Sequence Number) are used to maintain traceability.

• Dictionary Coding and Categorization Variables: Used when occurrence data is coded using standardized dictionaries like MedDRA or WHO Drug. Examples include AEDECOD (Dictionary-Derived Term for Adverse Event), AEBODSYS (Body System or Organ Class for Adverse Event), and AESOC (System Organ Class for Adverse Event). The ADDECODy variable (Analysis Dictionary-Derived Term y) is specifically introduced for grouping preferred terms for safety signal detection.

  Timing Variables: Capture the start and end dates/times of events, such as ASTDT (Analysis Start Date/Time) and AENDT (Analysis End Date/Time).

• Indicator Variables: Binary flags signifying specific conditions (e.g., TRTEMFL for Treatment Emergent Flag). New flags like TREMXXFL, TRTEMwFL, ONTRxxFL, and ONTRTWFL are provided for analyses involving multiple treatment periods or specific on-treatment definitions.

• Occurrence Flag Variables: Flags specific to whether an event occurred.

• Treatment/Dose Variables: Provide information related to the subject’s treatment or dose received, such as TRTA (Actual Treatment) and TRTAN (Actual Treatment Numeric).

• Descriptive Variables: Offer additional descriptive details about the event or observation.

• Standardized MedDRA Query Variables: Relate to variables derived from Standardized MedDRA Queries (SMQs).

• Original or Prior Coding Variables: Preserve original or previous coding information, particularly useful when data undergoes recoding.

• User-specified Variable Naming Conventions: Allows for custom naming conventions in specific scenarios.

“3.2.3.1 MedDRA Dictionary Coding Variables” describes common variables used for coding and categorizing medical terms, primarily for adverse events and medical history, using the MedDRA dictionary.

Here’s a summary of the key variables and their characteristics:

*--TERM (Reported Term): A character variable directly copied from the SDTM domain, representing the verbatim term reported. Its label can vary by SDTM domain. This is a required variable.

• --DECOD (Dictionary-Derived Term): A character variable representing the standardized dictionary-derived term, typically equivalent to the MedDRA Preferred Term (PT). It is conditionally required, especially for adverse event data, and should include the dictionary version in metadata.

• Hierarchical MedDRA Variables (--BODSYS, --BDSYCD, --LLT, --LLTCD, --PTCD, --HLT, --HLTCD, --HLGT, --HLGTCD, --SOC, --SOCCD): These variables capture different levels of the MedDRA hierarchy (System Organ Class, High Level Group Term, High Level Term, Lowest Level Term, and their corresponding codes).

• • For the ADVERSE EVENT SubClass, all levels of terms for the primary path in the MedDRA hierarchy are required.
• • For other OCCDS datasets, these variables are recommended but not required, and their core status can be conditional or permissible depending on their use in analysis.
• • They are copied from the SDTM domain or supplemental qualifiers and should include the dictionary version in their metadata.

• Type: Each variable is specified as either Char (character) or Num (numeric).

• Core and SubClass ADVERSE EVENT Core: These columns indicate the variable’s requirement status:

  • Req (Required): Must be present.
  • Cond (Conditionally Required): Required if certain conditions are met (e.g., if coded and used for analysis).
  • Perm (Permissible): Can be included if useful, but not strictly required.

• CDISC Notes: Provide additional context, derivation details (e.g., copied from SDTM), and specific considerations for each variable, including how they relate to primary and secondary coding paths in MedDRA.

In essence, this table outlines the essential and recommended variables for handling dictionary-coded data, particularly MedDRA, within ADaM OCCDS datasets, with specific emphasis on requirements for the Adverse Event SubClass due to its common use.

Table 3.2.3.1, “MedDRA Dictionary Coding Variables,” from the ADaM OCCDS Implementation Guide summarizes the variables used for standardizing and categorizing medical terms using the MedDRA (Medical Dictionary for Regulatory Activities) dictionary. These variables are crucial for adverse event and medical history analyses.

Here’s a breakdown of its key components: ::: {.callout-note}

• Variables Covered: The table lists numerous variables, each representing a level within the MedDRA hierarchy, along with the initial “reported term”:
  • --TERM (Reported Term)
  • --DECOD (Dictionary-Derived Term, equivalent to MedDRA Preferred Term)
  • --BODSYS (Body System or Organ Class)
  • --BDSYCD (Body System or Organ Class Code)
  • --LLT (Lowest Level Term)
  • --LLTCD (Lowest Level Term Code)
  • --PTCD (Preferred Term Code)
  • --HLT (High Level Term)
  • --HLTCD (High Level Term Code)
  • --HLGT (High Level Group Term)
  • --HLGTCD (High Level Group Term Code)
  • --SOC (Primary System Organ Class)
  • --SOCCD (Primary System Organ Class Code)

:::

• Variable Attributes: For each variable, the table specifies:
  • Variable Name: The standard naming convention (e.g., --TERM, --DECOD).
  • Variable Label: A descriptive label (e.g., “Reported Term”, “Dictionary-Derived Term”).
  • Type: Whether the variable is character (Char) or numeric (Num).
  • Codelist/Controlled Terms: Indicates if a controlled terminology (like MedDRA) is used.
  • Core: The general requirement status for OCCDS datasets (Required Req, Conditionally Required Cond, or Permissible Perm).
  • SubClass ADVERSE EVENT Core: The specific requirement status when the dataset is of the Adverse Event SubClass (these are generally more stringent for AE data). For instance, all primary path MedDRA hierarchy terms are required for the Adverse Event SubClass.
  • CDISC Notes: Provides important context, such as the source of the variable (e.g., copied from SDTM XX.--TERM or a supplemental qualifier), whether the dictionary version should be included in metadata, and specific conditions for its use or derivation.

Note

• Key Principles Highlighted:
  • Traceability: Variables are often copied directly from SDTM for traceability.
  • Hierarchy Importance: Emphasizes the importance of including all levels of the MedDRA hierarchy, especially for Adverse Events, to maintain the structured meaning of the dictionary.
  • Conditional Use: Many variables are conditional, meaning they are included only if the data is coded (e.g., for MedDRA) and relevant for the intended analysis.
  • Metadata: Stresses the need to include dictionary name and version in the metadata for each coding variable.
  • Primary vs. Secondary Paths: Notes that MedDRA allows for multiple SOCs for a single term and provides guidance for handling primary and secondary coding paths for analysis.

In essence, Table 3.2.3.1 serves as a comprehensive guide for producers on which MedDRA-related variables to include in their ADaM OCCDS datasets, how to name and define them, and their criticality, particularly when dealing with adverse event data.

Table 3.2.3.2, “WHO Drug Dictionary Coding Variables,” outlines the variables typically used for coding and categorizing concomitant medications using the WHO Drug Dictionary within ADaM datasets.

*Purpose: These variables are primarily used for concomitant medications (CM). They allow for standardization and categorization of drug names and their classifications.

Note

Variable Types and Examples: CMTRT (Reported Name of Drug, Med, or Therapy): A character variable directly copied from the SDTM CM domain, representing the reported drug name. This is a required variable.

*CMDECOD (Standardized Medication Name): A character variable representing the standardized drug name derived from the WHO Drug Dictionary. It’s often a primary variable for analysis and is conditionally required if coded and used for analysis.

• CMCLAS (Medication Class) and CMCLASCD (Medication Class Code): Character variables for the medication class and its code, copied from SDTM. These are permissible.
  • ATCy (ATC Level y Text) and ATCyCD (ATC Level y Code): Character variables representing the Anatomical Therapeutic Chemical (ATC) classification system levels (y can be 1-7). These are conditional based on whether analysis is performed at multiple ATC levels.
• SubClass ADVERSE EVENT Core: All variables listed in this table are explicitly marked as “Not Used” for the ADVERSE EVENT SubClass, indicating that WHO Drug coding variables are specific to concomitant medications and not adverse events.

Metadata Requirement: For all WHO Drug variables, it is crucial to include the dictionary version in the variable metadata. Single Coding Path: The variables shown are intended for a single WHO Drug coding path.

5.1.3 Table 3.2.3.3,

“Other Categorization Variables,” from the ADaM OCCDS Implementation Guide describes generic categorization variables used in ADaM datasets, often as alternatives or additions to dictionary-based coding (like MedDRA or WHO Drug).

• Purpose: These variables are used when categories are needed for analysis, either instead of or in addition to standardized dictionary coding. They provide a flexible way to group or classify data.
• Variables Covered:

  • --CAT (Category): A character variable copied directly from the SDTM domain (e.g., AE.AECAT, MH.MHCAT). It’s permissible for both general OCCDS and the Adverse Event SubClass. The variable label will differ depending on the SDTM domain it originates from.

  • --SCAT (Subcategory): A character variable, also copied from the SDTM domain, representing a subcategory of --CAT. It’s permissible for both general OCCDS and the Adverse Event SubClass. Similar to --CAT, its label is domain-dependent.

  • ACATy (Analysis Category y): A character variable that represents a category specifically derived for analysis purposes. It may be derived from --CAT and/or --SCAT. Examples include groupings for “prohibited medications,” “infusion associated reactions,” or other “special interest” categories not defined elsewhere or present in SDTM. This variable is permissible for both general OCCDS and the Adverse Event SubClass.

• Flexibility: These variables offer flexibility in analysis when a formal hierarchical dictionary might not be applicable or sufficient for the specific analytical needs.
• Core Status: All variables in this table are listed as “Permissible” (Perm) for both the general Core OCCDS and the SubClass ADVERSE EVENT Core, meaning they can be included if they are relevant for the analysis, but are not strictly required by default.

Table 3.2.4.1, “Timing Variables,” from the ADaM OCCDS Implementation Guide details the variables used to capture and derive timing information within ADaM datasets. These variables are crucial for establishing temporal relationships of events and observations to study milestones.

Here’s a summary of its key aspects:

• Source and Derivation: Timing variables are primarily:
  • Copied from SDTM: Variables ending in DTC (Date/Time Character) are directly copied from the corresponding SDTM domains (e.g., XX.--STDTC, XX.--ENDTC).
  • Derived within ADaM: Numeric date and datetime variables (e.g., ASTDT, AENDT, ASTDTM, AENDTM) are derived by converting their DTC counterparts and applying imputation rules as specified in the Statistical Analysis Plan (SAP) or metadata.
• Key Timing Variables:
  • Start Date/Time:
    • --STDTC (Start Date/Time of Observation): Character, ISO 8601 format, copied from SDTM.
    • ASTDT (Analysis Start Date): Numeric, derived from --STDTC.
    • ASTTM (Analysis Start Time): Numeric, derived from --STDTC.
    • ASTDTM (Analysis Start Datetime): Numeric, derived from --STDTC.
    • ASTDTF (Analysis Start Date Imputation Flag): Character (DATEFL), indicates if the analysis start date was imputed.
    • ASTTMF (Analysis Start Time Imputation Flag): Character (TIMEFL), indicates if the analysis start time was imputed.
  • End Date/Time: Similar sets of variables (--ENDTC, AENDT, AENTM, AENDTM, AENDTF, AENTMF) exist for the end of the observation.
• Relative Day Variables:
  • ASTDY (Analysis Start Relative Day): Numeric, derived as the number of days from an anchor date (e.g., ADSL.TRTSDT) to ASTDT. This variable may also be copied from --STDY.
  • --STDY (Study Day of Start of Observation): Numeric, copied from SDTM. This provides traceability as it may differ from ASTDY due to imputation or different reference dates.
  • AENDY (Analysis End Relative Day): Numeric, derived similarly to ASTDY but for the end date.
  • --ENDY (Study Day of End of Observation): Numeric, copied from SDTM, providing traceability to AENDY.
• Duration Variables:
  • ADURN (Analysis Duration (N)): Numeric, derived from analysis start and end dates/datetimes.
  • ADURU (Analysis Duration Units): Character (UNIT), specifies units for ADURN.
  • --DUR (Duration of XX): Character, ISO 8601, copied from SDTM. Included for traceability as it may differ from derived ADURN.
• Period/Phase Variables:
  • APERIOD (Period): Numeric, represents the analysis period within the study associated with the record (e.g., mapping to ADSL.TRTxxP).
  • APERIODC (Period (C)): Character, text characterizing the period, one-to-one map to APERIOD.
  • APHASE (Phase): Character, higher-level categorization of timing (e.g., SCREENING, ON TREATMENT, FOLLOW-UP).
• Core Status and SubClass ADVERSE EVENT Core: Most timing variables are Cond (Conditionally Required) or Perm (Permissible) for the general OCCDS. For the ADVERSE EVENT SubClass, many of the analysis timing variables (ASTDT, AENDT, ASTDY) become Req (Required) due to their critical role in defining treatment-emergent events and other analyses.
• Notes: The table emphasizes that variable labels for SDTM-copied variables may differ by domain. It also points to the ADaMIG for more detailed guidance on timing variables.

In summary, Table 3.2.4.1 comprehensively lists and defines the timing variables necessary for robust temporal analysis in ADaM OCCDS datasets, highlighting their source, derivation, and specific requirements, especially for adverse event analysis.

5.1.4 SDTM Indicator Variables, Table 3.2.5.1

• From the ADaM OCCDS Implementation Guide focuses on indicator variables directly copied from the Study Data Tabulation Model (SDTM) domains. These flags signal specific characteristics of observations.

Here’s a summary of its key points:

• Purpose: These variables indicate certain properties of the collected data directly from the source SDTM dataset. They are often used to filter data or define populations for analysis.
• Variables Covered:
  • --OCCUR (XX Occurrence):
    • Type: Character (Char).
    • Codelist: (NY) - typically “Y” for Yes, “N” for No.
    • Core: Conditionally Required (Cond). This means it’s included if the content is pertinent for analysis and populated in SDTM.
    • SubClass ADVERSE EVENT Core: Not Used (Not used). This is a crucial distinction: the SDTM does not permit the use of AEOCCUR (i.e., you won’t find a --OCCUR variable in the AE domain to indicate if an adverse event occurred or not, as all records in AE imply an occurrence). Therefore, this variable is not applicable to the Adverse Event SubClass in ADaM.
    • CDISC Notes: Copied from XX.--OCCUR.
  • --PRESP (XX Pre-Specified):
    • Type: Character (Char).
    • Codelist: (NY) - typically “Y” for Yes, “N” for No.
    • Core: Conditionally Required (Cond). Included if the content is pertinent for analysis and populated in SDTM.
    • SubClass ADVERSE EVENT Core: Conditionally Required (Cond). This variable is used for adverse events, for example, to indicate if a reported AE came from a pre-specified list.
    • CDISC Notes: Copied from XX.--PRESP.
• Key Takeaway: While both --OCCUR and --PRESP come directly from SDTM, their applicability within ADaM OCCDS, especially for the Adverse Event SubClass, differs significantly. --OCCUR is generally not used for AEs, while --PRESP is relevant across various occurrence data types, including AEs.
• Flexibility: The “Conditional” status emphasizes that these variables are included based on the study’s data collection and analysis needs.

5.1.5 “OCCDS Indicator Variables, Table 3.2.5.2”

describes a generic analysis flag (ANLzzFL) specifically designed for use within ADaM Occurrence Data Structure (OCCDS) datasets. Unlike the SDTM Indicator Variables, this variable is derived within ADaM, not directly copied from SDTM.

• Variable Covered:
  • ANLzzFL (Analysis Flag zz):
    • Type: Character (Char).
    • Codelist: Y (Yes). (Implicitly, it can also be N or null as described in ADaMIG v1.2 Section 3.3.8).
    • Core: Conditionally Required (Cond).
    • SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes:
      • This flag is highly versatile and useful in various analytical scenarios.
      • A common application is to distinguish between different coding paths (e.g., primary vs. secondary) when more than one is included for analysis. Separate ANLzzFL flags can be used for each path.
      • Its inclusion is conditional on whether analysis record flags are needed for the specific analysis.
• Purpose and Flexibility:
  • The ANLzzFL variable provides a mechanism to flag specific records within an OCCDS dataset for particular analytical purposes.
  • The zz suffix allows for multiple custom analysis flags (e.g., ANL01FL, ANL02FL, etc.) to be defined, catering to diverse analysis requirements beyond standard SDTM flags.
• Distinction from SDTM Flags:
  • It’s important to note that ANLzzFL is an ADaM-derived variable, not a direct copy from an SDTM domain. This allows for flagging based on complex analysis rules or derivations within the ADaM dataset itself.
  • This table focuses on a single, general-purpose analysis flag, setting the stage for more specific indicator variables related to adverse events and concomitant medications in subsequent tables.

5.1.6 Other Metadata (Section 3.3)

• Value-level Metadata: While generally not required for OCCDS due to its structure, it can be valuable in specific situations, such as for protocol deviations.

• Analysis Results Metadata: Although not strictly required by ADaM, providing analysis results metadata is considered a best practice. It helps consumers identify critical analyses, links results to supporting documentation and datasets, and clearly documents the analyses performed.

5.1.7 ANLzzFL (Analysis Flag zz)

• Table 3.2.5.2 describes the ANLzzFL (Analysis Flag zz) variable. This is a general-purpose, ADaM-derived indicator flag used to mark records for specific analytical purposes within an OCCDS dataset. It is conditionally required and highly flexible, allowing for multiple custom flags (e.g., ANL01FL, ANL02FL) to differentiate between various analytical contexts, such as primary or secondary coding paths.

5.1.8 “Adverse Events Indicator Variables, Table 3.2.5.3,

• ** focuses on common indicator flags specifically for adverse event data within ADaM OCCDS datasets. These variables are crucial for identifying events based on their temporal relationship to treatment.

• Focus: These flags are designed to categorize adverse events based on when they occurred relative to the study treatment.

• Key Variables:

  • TRTEMFL (Treatment Emergent Analysis Flag):
    • Type: Character (Char), with controlled term Y (Yes).
    • Core: Conditionally Required (Cond) for general OCCDS datasets.
    • SubClass ADVERSE EVENT Core: Required (Req). This is a critical flag for adverse event analysis.
    • CDISC Notes: Defines “treatment-emergent” for analysis purposes. Its derivation typically involves comparing the event’s analysis start date (ASTDT) with the subject’s treatment start and end dates (ADSL.TRTSDT, ADSL.TRTEDT), often including a “wash-out” period (e.g., + x days). This variable is central to most AE summaries.
  • TREMxxFL (Treatment Emergent Period xx Flag):
    • Type: Character (Char), with controlled term Y.
    • Core/SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes: Used when treatment emergence is analyzed across multiple periods (e.g., in cross-over studies). If included, TRTEMFL represents the overall treatment-emergent status.
  • TRTEMwFL (Treatment Emergent Analysis w Flag):
    • Type: Character (Char), with controlled term Y.
    • Core/SubClass ADVERSE EVENT Core: Permissible (Perm).
    • CDISC Notes: Allows for additional, customized treatment-emergent definitions (e.g., different cut-offs or criteria). If used, TRTEMFL remains the primary overall flag.
  • AETRTEM (Treatment Emergent Flag):
    • Type: Character (Char), with controlled terminology (NY).
    • Core: Permissible (Perm).
    • SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes: This is the SDTM-sourced treatment-emergent flag (from SUPPAE.QVAL where QNAM=“AETRTEM”). It’s included for traceability as its definition might differ from the derived TRTEMFL due to imputation or specific analysis rules.

• Relationship to Treatment: The core function of these variables is to define and categorize adverse events based on their timing relative to the administration of study treatment.

• Derivation: Most of these flags (TRTEMFL, TREMxxFL, TRTEMwFL) are derived within ADaM based on specific logic, while AETRTEM is copied from SDTM for traceability.

Important

• Importance: TRTEMFL is a foundational variable for many adverse event analyses, distinguishing events that occur or worsen during the active treatment phase. The other flags provide additional granularity for multi-period studies or alternative analysis definitions.

5.1.9 “Table Concomitant Medications Indicator Variables, 3.2.5.4,

• “details indicator flags specifically for concomitant medication data within ADaM OCCDS datasets. These variables primarily mark whether a medication was taken”on-treatment.”

• Focus: These variables are designed to categorize concomitant medications based on their timing relative to the study’s treatment period.

• Key Variables:

   * **`ONTRTFL` (On Treatment Record Flag):**
   * **Type:** Character (`Char`), with controlled term `Y` (Yes). (Can also be `N` or `null`).
   * **Core:** Conditionally Required (`Cond`).
   * **SubClass ADVERSE EVENT Core:** Permissible (`Perm`). This signifies that while it's a core concept for concomitant medications, it's less strictly required for AE datasets (which have their own `TRTEMFL`).
   * **CDISC Notes:** Indicates whether the medication observation occurred while the subject was on treatment. Its derivation typically involves comparing the medication's analysis start date (`ASTDT`) with the subject's treatment start and end dates (`ADSL.TRTSDT`, `ADSL.TRTEDT`). It's conditional on whether the "on treatment" concept is a feature of the study's analysis.

  • ONTRxxFL (On Treatment Period xx Flag):
    • Type: Character (Char), with controlled term Y.
    • Core/SubClass ADVERSE EVENT Core: Permissible (Perm).
    • CDISC Notes: Used if “on treatment” status needs to be tracked across multiple treatment periods (e.g., in complex study designs). If used, ONTRTFL would serve as the overall on-treatment flag.
  • ONTRTwFL (On Treatment Record w Flag):
    • Type: Character (Char), with controlled term Y.
    • Core/SubClass ADVERSE EVENT Core: Permissible (Perm).
    • CDISC Notes: Allows for other analysis needs or different cut-offs for defining “on treatment” periods. Similar to ONTRxxFL, if used, ONTRTFL would be the overall on-treatment flag.

• Relationship to Treatment: The primary function of these variables is to link concomitant medication usage to the patient’s treatment exposure period.

• Derivation: All flags in this table (ONTRTFL, ONTRxxFL, ONTRTwFL) are derived within ADaM based on specific logical rules. They are not directly copied from SDTM.

Important

• Importance: ONTRTFL is a key indicator for analyzing concomitant medications in relation to treatment exposure, helping to understand potential drug-drug interactions or medication adherence during study treatment. The xx and w variants provide flexibility for more granular or alternative definitions.

5.1.10 “Adverse Event and Concomitant Medications Indicator Variables, Table 3.2.5.5”

• presents two general timing-related indicator flags that can be applied to both adverse event and concomitant medication data within ADaM OCCDS datasets. These flags categorize observations based on whether they occurred before treatment or during follow-up.

• Broad Applicability: Unlike the previous tables that focused specifically on AEs or CMs, the variables in this table are designed to be applicable across both adverse events and concomitant medications (and potentially other occurrence data types).

• Key Variables:

  • PREFL (Pre-treatment Flag):
    • Type: Character (Char), with controlled term Y (Yes).
    • Core: Conditionally Required (Cond).
    • SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes: Indicates whether the observation (event or medication) occurred before the subject started treatment. Its derivation typically compares the event’s analysis start date (ASTDT) with the subject’s treatment start date (ADSL.TRTSDT). Its inclusion is conditional on whether the concept of “pre-treatment” is relevant for the study’s analysis.
  • FUPFL (Follow-up Flag):
    • Type: Character (Char), with controlled term Y (Yes).
    • Core: Conditionally Required (Cond).
    • SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes: Indicates whether the observation occurred while the subject was in the follow-up period (i.e., after treatment exposure ended). Its derivation typically compares ASTDT with the subject’s treatment end date (ADSL.TRTEDT). Its inclusion is conditional on whether the concept of “follow-up” is relevant for the study’s analysis.

• Derivation: Both PREFL and FUPFL are derived variables within ADaM, based on the ASTDT and ADSL timing variables. They are not directly copied from SDTM.

Important

• Importance: These flags are essential for segmenting occurrence data into distinct time periods relative to treatment. This allows for analyses that differentiate between pre-treatment baseline events, events during active treatment (captured by TRTEMFL or ONTRTFL), and events occurring during the post-treatment follow-up phase. They help provide a complete picture of event occurrences across the study timeline.

5.1.11 “OCCDS Occurrence Flag Variables Table 3.2.6.1”

describes a set of derived flags used to identify the “first occurrence” of events or observations within an ADaM Occurrence Data Structure (OCCDS) dataset.

These flags are created based on specific sorting and flagging rules, primarily to support analyses that count unique subjects or events.

• Purpose: These flags are designed to mark a single “first” record among multiple occurrences for a subject, based on various criteria. This helps in preparing data for analyses that focus on unique events (e.g., “number of subjects with at least one event”).

• Nature of “First”: The “first” occurrence does not necessarily imply the earliest chronological event. Instead, it refers to the first record identified after sorting the data according to predefined rules (e.g., by subject, date, severity, or term).

• Key Variables (All are Character Type ‘Y’ and Permissible ‘Perm’):

  • AOCCFL (1st Occurrence within Subject Flag): Flags the very first occurrence of any event/intervention/finding for a given subject. The derivation typically involves sorting by subject and then flagging the first treatment-emergent record.

  • AOCCPFL (1st Occurrence of Preferred Term Flag): Flags the first occurrence of a specific preferred term (--DECOD) within a subject. This is useful when counting unique subjects per preferred term.

  • AOCCIFL (1st Max Sev./Int. Occurrence Flag): Flags the first occurrence of an event that has the maximum severity/intensity for a given subject. This helps in analyses focused on the worst outcome.

  • AOCCPIFL (1st Max Sev./Int. Occur Within PT Flag): Flags the first occurrence of an event that has the maximum severity/intensity within a specific preferred term for a given subject.

  • AOCCzzFL (1st Occurrence of …): A placeholder for additional, user-defined occurrence flags. If such flags are added, their specific derivation rules must be documented in the metadata.

• Derivation: All variables in this table are derived within ADaM. Their creation involves sorting the dataset by various criteria (subject, term, severity, sequence number) and then identifying the first record based on that sorted order.

• Core Status: All these flags are classified as Perm (Permissible) for both general OCCDS and the Adverse Event SubClass. This indicates that they are not strictly required but are highly recommended and useful for facilitating data-point traceability between individual records and aggregated counts in summary displays. They also provide a crucial link for time-to-event analyses.

• Relationship to Traceability: These flags play a vital role in connecting the detailed records in the OCCDS dataset to the unique counts presented in analysis summaries, ensuring consistency and accuracy in reporting.

5.1.12 “MedDRA Occurrence Flag Variables ,Table 3.2.6.2,”

details a set of derived flags specifically designed for identifying the “first occurrence” of ** adverse events (or other MedDRA-coded events) based on different levels of the MedDRA hierarchy within an ADaM Occurrence Data Structure (OCCDS) dataset **.

• Specific to MedDRA Hierarchy: These flags are distinct from the more general OCCDS occurrence flags (Table 3.2.6.1) as they leverage the hierarchical structure of MedDRA (e.g., System Organ Class - SOC).

• Purpose: The primary goal is to identify unique occurrences for counting purposes at different MedDRA levels, supporting analyses that summarize events by SOC.

• Key Variables (All are Character Type ‘Y’ and Permissible ‘Perm’):

  • AOCCSFL (1st Occurrence of SOC Flag):
    • Flags the first occurrence of an event within a specific System Organ Class (SOC) for a given subject.
    • Derivation Example: Sort data by subject, then by SOC, followed by analysis start date and sequence number, and flag the first treatment-emergent record.
  • AOCCSIFL (1st Max Sev./Int. Occur Within SOC Flag):
    • Flags the first occurrence of the event with the maximum severity/intensity within a specific System Organ Class (SOC) for a given subject.
    • Derivation Example: Sort data by subject, then by SOC, then by descending analysis severity/intensity (N), and finally by sequence number, flagging the first treatment-emergent record.

• Derivation: Both variables are derived within ADaM, using specific sorting rules that incorporate MedDRA levels and potentially severity.

• Core Status: Both flags are classified as Perm (Permissible) for both general OCCDS and the Adverse Event SubClass. This indicates that while not strictly mandatory, they are valuable for analyses summarizing events by MedDRA categories, especially for adverse events.

Note

• Relevance: These flags are particularly useful for creating summary tables where adverse events are grouped and counted by SOC, and for identifying the most severe or first-occurring event within that classification.

5.1.13 “Treatment/Dose Variables,Table 3.2.7.1,”

outlines variables in ADaM OCCDS datasets that are related to treatment assignment, actual dose received, and cumulative dose exposure. These variables are fundamental for analyzing the impact of treatment and dose on observed occurrences.

• Primary Purpose: To include essential treatment and dosing information necessary for analysis, either copied from the Subject-Level Analysis Dataset (ADSL) or derived at the record level.

• Key Variables:

  • Treatment Variables (e.g., TRTP, TRTA, TRTxxP, TRTxxA):
    • While not explicitly listed with their full details in this table, the CDISC Notes state that “Typically, this would be TRTP, TRTA, TRTxxP, or TRTxxA.” These variables represent planned or actual treatment and are generally copied from ADSL. They are crucial for grouping subjects by treatment arm in analyses.
  • DOSEON (Treatment Dose at Record Start):
    • Type: Numeric (Num).
    • Core/SubClass ADVERSE EVENT Core: Permissible (Perm).
    • CDISC Notes: Represents the dose a subject received at the start of the event/observation record. It’s typically derived by linking to the Exposure (EX) domain (EX.EXDOSE) where the event’s start date/time falls within the exposure period.
  • DOSCUMA (Cumulative Actual Treatment Dose):
    • Type: Numeric (Num).
    • Core/SubClass ADVERSE EVENT Core: Permissible (Perm).
    • CDISC Notes: Represents the cumulative actual study drug dosage up to the start of the event/observation record. This is a derived variable, summing doses from the EX domain.
  • DOSEU (Treatment Dose Units):
    • Type: Character (Char), with (UNIT) codelist.
    • Core/SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes: Specifies the units for DOSEON and/or DOSCUMA. It’s conditional on whether these dose variables are included.

• Derivation and Source:

  • Record-level dose variables like DOSEON and DOSCUMA are derived within ADaM, often by integrating data from the SDTM Exposure (EX) domain.
  • Treatment arm variables (like TRTP, TRTA) are typically copied from ADSL.

Important

• Importance: These variables are vital for dose-response analyses, examining the relationship between drug exposure (single dose or cumulative) and the occurrence of events. They allow for a more nuanced understanding of safety and efficacy profiles.
• Flexibility: All variables in this table are “Permissible” or “Conditionally Required,” indicating that their inclusion depends on the specific analytical needs of the study, particularly regarding dose-related assessments.

5.1.14 “Adverse Event Descriptive Variables,Table 3.2.8.1,”

details a range of variables used to describe the characteristics of adverse events within ADaM OCCDS datasets, specifically for the Adverse Event SubClass (ADAE). These variables often have both SDTM-copied versions and ADaM-derived “analysis” versions, particularly to handle imputation or pooling.

• Purpose: To include descriptive information about adverse events that is often used in analyses, such as severity, causality, and toxicity grade.

• SDTM-Copied vs. Analysis-Derived Versions: A common theme is the presence of both direct copies from SDTM and new ADaM-derived “analysis” versions (prefixed with “A”). The analysis versions (ASEV, AREL, ATOXGR) allow for:

  • Imputation of Missing Data: Applying rules (from the SAP or metadata) to fill in missing severity or causality values.

  • Standardization/Normalization: Changing the case of text (e.g., from “SEVERE” to “Severe”).

  • Pooling/Grouping: Creating pooled categories for analysis (e.g., RELGRy, TOXGGRy).

  • Numeric Conversion: Providing numeric equivalents of character grades (e.g., ASEVN, ARELN, ATOXGRN).

• Key Variables:

  • --SER (Serious Event): Character (Y/N), copied from AE.AESER. Permissible (Perm) in general OCCDS, but Required (Req) for SubClass ADVERSE EVENT.

  • Severity/Intensity:

    • --SEV (Severity/Intensity): Character (e.g., MILD, MODERATE, SEVERE), copied from AE.AESEV. Permissible, Conditionally Required for SubClass ADVERSE EVENT if AE.AESEV is present (either --SEV or --TOXGR should be in SDTM).
    • --SEVN (Severity/Intensity (N)): Numeric (1, 2, 3), coded from --SEV. Permissible.
    • ASEV (Analysis Severity/Intensity): Character (e.g., Mild, Moderate, Severe), derived. Permissible.
    • ASEVN (Analysis Severity/Intensity (N)): Numeric (1, 2, 3), coded from ASEV. Permissible.
    • SEVGRy (Pooled Severity Group y): Character, derived for pooled groupings (e.g., “mild/moderate”, “severe”). Permissible.
    • SEVGRyN (Pooled Severity Group y (N)): Numeric, coded from SEVGRy. Permissible.

• Causality: * --REL (Causality): Character (e.g., NOT RELATED, POSSIBLY RELATED), copied from AE.AEREL. Permissible, Required for SubClass ADVERSE EVENT. * --RELN (Causality (N)): Numeric, coded from --REL. Permissible. * AREL (Analysis Causality): Character, derived. Permissible. * ARELN (Analysis Causality (N)): Numeric, coded from AREL. Permissible. * RELGRy (Pooled Causality Group y): Character, derived for pooled groupings (e.g., “Related”, “Not Related”). Permissible. * RELGRyN (Pooled Causality Group y (N)): Numeric, coded from RELGRy. Permissible.

• Toxicity Grade: (Often used in oncology studies) * --TOXGR (Standard Toxicity Grade): Character, copied from AE.AETOXGR. Permissible, Conditionally Required for SubClass ADVERSE EVENT if AE.AETOXGR is present. * --TOXGRN (Standard Toxicity Grade (N)): Numeric, coded from --TOXGR. Permissible. * ATOXGR (Analysis Toxicity Grade): Character, derived. Permissible. * ATOXGRN (Analysis Toxicity Grade (N)): Numeric, coded from ATOXGR. Permissible. * TOXGGRy (Pooled Toxicity Grade Group y): Character, derived. Permissible. * TOXGGRyN (Pooled Toxicity Grade Group y (N)): Numeric, coded from TOXGGRy. Permissible.

  • --ACN (Action Taken with Study Treatment):** Character (ACN codelist), copied from AE.AEACN. Permissible, Conditionally Required if present and populated in SDTM.

• Importance for AE Analysis: These descriptive variables are fundamental for characterizing adverse events and performing analyses that categorize or summarize AEs by their severity, relationship to treatment, or toxicity. The “analysis” versions allow for data manipulation to meet specific analytical needs while maintaining traceability to the source SDTM data.

• Other SDTM Variables: The table notes that other relevant SDTM variables (e.g., AEOUT, AESDTH) should also be included if used in analysis.

• Medical History Note: For medical history data, similar descriptive variables can be used by replacing the “AE” prefix with “MH”.

5.1.15 “Concomitant Medications Descriptive Variables, Table 3.2.8.2,”

lists common variables used to describe concomitant medications within ADaM OCCDS datasets (ADCM). These variables provide additional context beyond just the medication name, allowing for more detailed analyses of medication usage.

Here’s a summary of its key points:

• Purpose: To include descriptive information about concomitant medications that is often utilized in analyses, such as the medication’s status, indication, dose, and administration route.
• Source: All variables listed in this table are typically copied directly from the SDTM CM domain.
• Key Variables (All are Character Char type and Permissible Perm for general OCCDS):
  • --STAT (Completion Status): Describes the status of the medication record (e.g., ongoing, completed).
  • --INDC (Indication): Specifies the medical reason for which the concomitant medication was prescribed or taken.
  • --DOSE (Dose per Administration): Records the dose of the medication taken per administration.
  • --DOSFRM (Dose Form): Describes the physical form of the medication (e.g., tablet, capsule, liquid).
  • --DOSRGM (Intended Dose Regimen): Specifies the intended dosing regimen.
  • --ROUTE (Route of Administration): Indicates how the medication was administered (e.g., oral, intravenous).
• SubClass ADVERSE EVENT Core: All variables in this table are explicitly marked as “Not Used” for the ADVERSE EVENT SubClass. This reinforces that these descriptive variables are specific to concomitant medications and are not relevant for adverse event analysis datasets.

Important

• Importance for CM Analysis: These descriptive variables enhance the analysis of concomitant medications by providing context about how and why they were used, which can be crucial for understanding potential drug interactions, adherence, or patient characteristics.

5.1.16 “Standardized MedDRA Query (SMQ) Variables,Table 3.2.9.1,”

describes variables used to identify and categorize medical events based on Standardized MedDRA Queries (SMQs) and Customized Queries (CQs) within ADaM datasets. These are crucial for safety evaluations, especially when investigating known or suspected safety issues.

• Purpose: To incorporate pre-defined or customized groupings of MedDRA terms (SMQs and CQs) into analysis datasets, allowing for focused safety surveillance.

• SMQ Variables (where zz is a zero-padded 2-digit integer, e.g., 01-99):

  • SMQzzNAM (SMQ zz Name):
    • Type: Character (Char).
    • Core/SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes: Contains the full name of the Standardized MedDRA Query (e.g., “Haemorrhage terms (excl. laboratory terms) (SMQ)”). It would be blank for terms not included in the specific SMQ. Included if SMQ analysis is performed.
  • SMQzzCD (SMQ zz Code):
    • Type: Numeric (Num).
    • Core/SubClass ADVERSE EVENT Core: Permissible (Perm).
    • CDISC Notes: Contains the numeric code for the SMQ from MedDRA.
  • SMQzzSC (SMQ zz Scope):
    • Type: Character (Char), with controlled terms “BROAD” or “NARROW”.
    • Core/SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes: Indicates the search strategy scope (narrow for high specificity, broad for high sensitivity). Null if the term doesn’t meet the SMQ criteria. Important for understanding summary percentages.
  • SMQzzSCN (SMQ zz Scope (N)):
    • Type: Numeric (Num), with controlled terms 1 (for BROAD) and 2 (for NARROW).
    • Core/SubClass ADVERSE EVENT Core: Permissible (Perm).
    • CDISC Notes: Numeric equivalent of SMQzzSC. Null if the term doesn’t meet the SMQ criteria.

• Customized Query Variables:

  • CQzzNAM (Customized Query zz Name):
    • Type: Character (Char).
    • Core/SubClass ADVERSE EVENT Core: Conditionally Required (Cond).
    • CDISC Notes: The name of a sponsor-defined customized query or adverse event of special interest category. Would be blank for terms not in the CQ. Included if CQ analysis is performed. Examples include “DERMATOLOGICAL EVENTS,” “CARDIAC EVENTS.”

• Combined Analysis Term Variable:

  • ADECODy (Analysis Dictionary-Derived Term y):
    • Type: Character (Char).
    • Core/SubClass ADVERSE EVENT Core: Permissible (Perm).
    • CDISC Notes: This variable is used for analysis when combining multiple customized or standardized MedDRA queries and/or original MedDRA dictionary terms under a single variable. While designed for MedDRA queries, it can be used for other OCCDS analysis needs.

Important

• General Notes:
  • The zz suffix allows for multiple SMQs/CQs of interest (01-99).
  • Their inclusion is conditional on whether SMQ or CQ analysis is being performed.
  • The table emphasizes the importance of understanding the scope (narrow vs. broad) for SMQs, as it significantly impacts summary results.
  • These variables are fundamental for advanced safety signal detection and reporting in clinical trials.

5.1.17 “Original or Prior MedDRA Coding Variables, Table 3.2.10.1,”

describes a set of variables used to retain MedDRA coding information from previous dictionary versions or analyses within an ADaM dataset. This is particularly useful for traceability and comparison when dictionary versions change over time or when integrating data from studies that used different versions.

• Purpose: To provide traceability back to original or prior MedDRA coding, which is crucial in scenarios like:

  • Studies where interim analyses used an older dictionary version, and the final analysis uses a newer one.

  • Integrated analyses pooling data from multiple studies that were coded using different MedDRA versions.

  • Ensuring consistency and the ability to reproduce previous analysis results despite dictionary updates.

• Variables Covered (all are Character Char type and Permissible Perm for both general OCCDS and Adverse Event SubClass):

  • The variables mirror the standard MedDRA hierarchy, but with an ORGw suffix (for “Original”) and an integer w (1-9) to denote the specific prior version.

  • DECDORGw (PT in Original Dictionary w): Original preferred term coding.

  • BDSYORGw (SOC in Original Dictionary w): Original body system coding.

  • HLGTORGw (HLGT in Original Dictionary w): Original High Level Group Term coding.

  • HLTORGw (HLT in Original Dictionary w): Original High Level Term coding.

  • LLTORGw (LLT in Original Dictionary w): Original Lowest Level Term coding.

  • LLTNORGw (LLT Code in Original Dictionary w): Original Lowest Level Term code.

• Metadata Requirement: For each ORGw variable, the dictionary name and specific version (MedDRAw version X.X) must be included as part of the metadata. This is critical for accurate interpretation and traceability.

• Derivation/Source: These variables would be populated with the MedDRA terms/codes that were applicable at the time of the “original” or “prior” coding, even if the primary analysis variables are based on a newer dictionary version.

Note

• Naming Convention Note: The table explicitly states that these variable names are currently recommendations only. An ADaM subteam working on integration might define different naming conventions in the future. Additional prior/original variables can be added following similar conventions.

In summary, Table 3.2.10.1 provides a standardized way to preserve historical MedDRA coding information within ADaM datasets, which is vital for maintaining data integrity and facilitating comparisons across different dictionary versions or integrated analyses.

5.1.18 “Original or Prior WHO Drug Coding Variables, Table 3.2.10.2,”

describes a set of variables used to preserve WHO Drug Dictionary coding information from previous dictionary versions or analyses within an ADaM dataset. This is analogous to the MedDRA prior coding variables and serves similar traceability and comparison purposes for concomitant medications.

Here’s a summary of its key points:

• Purpose: To provide traceability to original or prior WHO Drug coding for concomitant medications. This is important when:

  • A study’s medication data is re-coded with a newer WHO Drug version for final analysis.
  • Data from multiple studies, coded with different WHO Drug versions, are pooled for an integrated analysis.
  • It ensures the ability to reproduce previous analysis results and compare data across different dictionary versions.

• Variables Covered (all are Character Char type and Permissible Perm for general OCCDS; “Not Used” for Adverse Event SubClass, consistent with other WHO Drug variables):

  • The variables mirror the standard WHO Drug classification, but with an ORGw suffix (for “Original”) and an integer w (1-9) to denote the specific prior version.
  • DECDORGw (Standardized Med Name in Orig Dict w): Original standardized medication name.
  • CLASORGw (Medication Class in Orig Dictionary w): Original medication class.
  • CLCDORGw (Medication Class Code in Orig Dict w): Original medication class code.
  • ATyCORGw (ATC Level y Code in Orig Dictionary w): Original ATC Level y code.
  • ATyTORGw (ATC Level y Text in Orig Dictionary w): Original ATC Level y text.

• Context: These variables are specifically for concomitant medication data (linking back to CM.CMTRT). They are “Not Used” for the Adverse Event SubClass.

• Metadata Requirement: For each ORGw variable, the dictionary name and specific version (WHODRUGw version X.X) must be included as part of the metadata. This is crucial for precise identification of the original coding context.

• Derivation/Source: These variables are populated with the WHO Drug terms/codes that were applicable at the time of the “original” or “prior” coding, even if the primary analysis variables are based on a newer dictionary version.

• Naming Convention Note: Similar to the MedDRA prior variables, the table notes that these variable names are currently recommendations only, and future ADaM integration work might lead to different conventions.

Note

In summary, Table 3.2.10.2 provides a standardized approach for preserving historical WHO Drug coding information within ADaM datasets for concomitant medications, ensuring data traceability and facilitating comparisons across different dictionary versions or integrated analyses.

5.1.19 “User-specified Variable Naming Conventions, Section 3.2.11,”

provides guidelines for naming new, custom variables created within ADaM datasets that are not explicitly defined in the ADaM Implementation Guide (ADaMIG) or this Occurrence Data Structure (OCCDS) document. It emphasizes the importance of clear, consistent naming to convey the variable’s origin and potential modifications.

1. Harmonization Principle:

   • ADaM strongly adheres to a “same name, same meaning, same values” principle for variables copied directly from SDTM. If an SDTM variable name is used in ADaM, its label and content must remain identical to the SDTM source.

2. “A” Prefix for “Analysis” Versions (Modified Content):

   • When a modified version of an SDTM variable is needed (e.g., due to imputation of missing data, changes in case, or other analytical derivations), the original 2-letter SDTM domain code (e.g., “AE” for Adverse Events, “MH” for Medical History) is replaced with the prefix “A” (for Analysis).

   • Example: If AEBODSYS from SDTM is modified for analysis (e.g., missing values imputed), the new analysis variable would be named ABODSYS. This immediately signals that ABODSYS is an analysis version and its values may not be identical to the original AEBODSYS on some records.

   • This convention applies even if the original SDTM variable is not explicitly listed in the ADaMIG.

3. “U” Prefix for “Unmodified” Stacked Variables (Unchanged Content, Consolidated Column):

   • When records from multiple SDTM domains (or ADaM datasets) need to be combined into a single variable in the analysis dataset, but the content of the original SDTM variables remains unmodified, the prefix “U” (for unmodified) can be used.

   • Scenario: This is particularly useful when stacking similar data from different SDTM domains into one column for analysis readiness. For example, combining AEBODSYS from the AE domain and MHBODSYS from the MH domain into a single UBODSYS column in the OCCDS.

   • Distinction from “A” Prefix: Using “U” clarifies that no modifications were made to the content of the underlying SDTM variables; it’s simply a consolidation of data from different sources into a single analysis column. If any modification (imputation, case change, etc.) were made during this stacking process, the “A” prefix (ABODSYS) would be more appropriate.

   • Example: Combining AEBODSYS and MHBODSYS (if their content is exactly as in SDTM) into a single analysis variable UBODSYS.

4. Fragments and Conventions:

   • The ADaMIG provides variable name fragments and other conventions (often used with ADSL and BDS datasets). While OCCDS datasets may have fewer derived variables, these conventions help create easily understood variable names.
   • The goal is to build clear and self-documenting variable names that immediately convey whether the variable is a direct copy, an analysis version, or an unmodified stacked variable from multiple sources.

In summary, Section 3.2.11 provides crucial guidance for maintaining consistency and clarity in ADaM datasets when creating new or derived variables, especially when dealing with modifications or stacking data from multiple source domains. The “A” and “U” prefixes are key tools for indicating the variable’s derivation and content integrity.

Note

This Chapter 3 provides a comprehensive guide to defining and documenting ADaM OCCDS datasets. By adhering to these metadata standards, researchers ensure that clinical trial data is structured, transparent, traceable, and readily available for robust statistical analysis and regulatory review.