ADaM Standards - PowerPoint PPT Presentation

ADaM Standards

Wouter van Wyk

• SDTM purpose is to provide collected data
• Not designed for ease of analysis
• ADaM purpose is to provide data that is ready for analysis
• Is designed for ease of analysis
• “1 proc away”
• ADaM helps the reviewer trace:
• What you said you would do
• What you did
• TRACEABILITY is of utmost importance

• Traceability permits the understanding of the relationship between the analysis results, the analysis datasets and the SDTM datasets.
• Traceability is built by clearly establishing the path between an element and its predecessor(s)
• Traceability establishes across-dataset relationships, as well as within-dataset relationships.
• Traceability = Transparency

Analysis Result

Annotated shells

ADaM Dataset

ADaM Specs (Define.xml)

Traceability variables

(in dataset)

It should be easy to trace where a value came from

SDTM Dataset

• Metadata traceability
• How was a variable or observation derived?
• ADaM Specifications, Define.xml
• Data point traceability
• Which observations were used to derive a value of observation?
• Traceability variables in the ADaM dataset
• E.g. SRCVAR, SRCDOM, SRCSEQ

• At least ADSL should be created
• Not all data from SDTM needs to go into ADaM
• There is not a 1:1 relationship between ADaM and SDTM
• 1 SDTM dataset could map to multiple ADaM Datasets
• Many SDTM datasets could map to the same ADaM Dataset
• Some of the SDTM data will be present in more than 1 ADaM Dataset
• Create the optimum number of ADaM datasets as required for analysis
• E.g. If Medical History is not summarized, you don’t need to create an ADaM dataset for it.

• If the variable is straight from SDTM it
• must have the same attributes
• must have the same contents
• may not be modified in any way
• See the ADaM Implementation Guide on naming conventions and controlled terminology.

• Subject Level Structure (ADSL)
• Reserved dataset name ‘ADSL’
• One record per subject, regardless of study design
• Basic Data Structure (BDS)
• Designed with the majority of analysis files in mind
• One or more records per subject per analysis parameter, per analysis time point (if applicable)
• Most if not all the by Visit domains (Findings) from SDTM would fit in this structure
• Adverse Events does not fit the BDS Structure
• You can create your own class if these 2 are not appropriate

• Contains important information about a subject
• Structured as one record per subject
• Regardless of clinical trial design
• Allows for easy merging with any other ADaM or SDTM dataset
• Used as a source for
• Variables required in other analysis datasets
• Denominator values for populations of interest
• Contains some Required variables

• Primary source of subject-level variables included in other analysis datasets
• Variables describe attributes of a subject as well as the subject’s experience in trial (e.g. date of death)
• Not intended to be the only file that supports subject level data
• E.g. if efficacy analysis is time to event, create ADTTE file instead of putting everything in ADSL
• Standard Disposition and Demographics tables should be able to be created from ADSL

• Study and subject identifiers
• Subject demographics
• Population indicators
• Treatment variables
• Trial dates
• Stratification variables
• Treatment duration and possibly compliance variables
• See the ADaM IG for possible ADSL variables

• Flexible enough for the majority of analyses
• Vertical structure: can be thought of as one or more records

per subject (USUBJID)

per analysis parameter (PARAM, PARAMCD)

per analysis time point (AVISIT, ADY)

• Even though similar in structure to the SDTM Findings domains (think of VS, LB and EG) if is not a replica and could contain any type of data
• An Event
• A Finding
• An Intervention
• Completely derived observation that is created from multiple types of SDTM data

• The BDS domains have an “Analysis-focused” design
• One proc away
• Supportive columns may be added as appropriate
• Named ADxxxxxx, where then ‘x’ denotes a name of your choosing
• ADVS
• ADLB
• ADTTE
• ADEFF

• ADSL Variables
• Keep only what is needed
• STUDYID, USUBJID at minimum
• BDS Analysis Parameter Variables
• BDS Analysis Value Variables
• BDS Analysis Timing Variables
• BDS Analysis Descriptor Variables
• BDS Indicator Variables
• BDS Analysis Population Indicators
• BDS Analysis Enabling Variables
• BDS Data Point Traceability Variables

• Variables to describe what is being analyzed
• Required
• PARAM - Parameter Description
• Value of PARAM should be what appears on statistical tables
• Uniquely describes what is contained in the Analysis variable
• Includes: test name, unit, position, location etc
• PARAMCD – 8 character version of PARAM
• Other
• PARAMN

• Variables that contain numeric of character values that are analyzed
• At least one of the following is required
• AVAL: numeric result as described by PARAM
• AVALC: character result as described by PARAM
• Other
• BASE: numeric baseline result
• BASEC: character baseline result
• CHG: change from baseline
• PCHG: Percent change from baseline
• SHIFTy: function of defined pairs,
• Such as shift from baseline - ‘Normal to Abnormal’

• Use when there are derived observations within a PARAM
• DTYPE: e.g. LOCF, WOCF, AVERAGE
• Use where there is windowing
• AWRANGE, AWLO, AWHI: Analysis window valid range
• AWTARGET: Analysis window target day
• AWDIFF: Difference from target day
• AWU: Unit of AWLO, AWHI
• Use in time-to event analysis
• STARTDT: Original date of risk for the TTE analysis
• CNSR: Defines whether the event is censored
• EVENTDESC: Description of the event of interest or censoring reason
• The actual time to event result will be in AVAL

• Conventions:
• Character variable will end in *FL
• Y/N/Null
• Numeric variable will end in *FN
• 1/0/Null
• Examples:
• ABLFL: Baseline flag
• ANLzzFL: Analyzable flag
• ONTRTFL: On-treatment flag

• A variable is supportive if it is not required in order to perform an analysis but is included in order to facilitate traceability
• Retaining certain SDTM variables
• --SEQ, VISIT, VISITNUM, --DY, ARM, ARMCD\
• Additional variables
• SRCDOM: Domain of origin for value contained in AVAL (e.g. ”LB”)
• SRCVAR: Variable name used to create AVAL (e.g. “LBSTRESN”)
• SRCSEQ: Sequence number to identify record used (e.g. = LBSEQ)

• Some kinds of data do not fit in the BDS Structure
• E.g. Adverse Events, Concomitant Medications
• Create your own structure based on ADaM principles
• Dataset name should start with “AD”
• SDTM variables should not be modified, rather create new variable and keep the SDTM variable for traceability
• Dataset should be analysis ready, one proc away
• Follow naming conventions
• Ensure traceability back to the source data
• ADAE could mean you only need to merge ADSL with SDTM.AE and create a few numeric dates as needed, but will be driven by what analyses need to be done.

• www.cdisc.org/adam
• www.lexjansen.com
• www.phuse.eu