ADaM Standards

1. ADaM Standards Wouter van Wyk

2. Why ADaM • 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

3. What is Traceability? • 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

4. What is Traceability? 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

5. 2 Kinds of Traceability • 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

6. ADaM Rules for Analysis Datasets • 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.

7. ADaM Rules for Analysis Datasets • 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.

8. Classes of ADaM structures • 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

9. SDTM and ADaM “Core” Definitions

10. Analysis Data Subject Level - ADSL • 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

11. Analysis Data Subject Level - ADSL • 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

12. What goes into 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

13. Basic Data Structure - BDS • 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

14. Basic Data Structure - BDS • 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

15. What goes into BDS? • 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

16. BDS Analysis Parameter 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

17. BDS Analysis Value Variables • 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’

18. Some BDS Analysis Descriptor Variables • 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

19. BDS Indicator Variables • 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

20. BDS Data Point Traceability Variables • 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)

21. What to do with Adverse Events? • 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.

22. Some useful websites • www.cdisc.org/adam • www.lexjansen.com • www.phuse.eu

23. Any Questions?