© 2011 octagon research solutions, inc. all rights reserved. the contents of this document are...

© 2011 Octagon Research Solutions, Inc. All Rights Reserved. The contents of this document are confidential and proprietary to Octagon Research Solutions, Inc.

Implications for ADaM of the recently released

CDER Common Issues document and draft SDTM Amendment 1

July, 2011

Prepared and Presentedby Octagon Research Solutions

© 2011 Octagon Research Solutions, Inc. All Rights Reserved. The contents of this document are confidential and proprietary to Octagon Research Solutions, Inc.2

Content with ADaM Implications

• General – Reference documents – Splitting large datasets

• ADaM Content – Coded and imputed data– Expected analysis datasets – Baseline variables needed in ADSL

• Traceability – Tracing ADaM back to SDTM – Consistency across all datasets, including between SDTM and ADaM – Permissible variables expected in SDTM – New required and expected SDTM variables – Derivation of --STDY in SDTM – SDTM SUPPQUAL variables that support key analyses

• Integration – Common dictionaries across a submission – Multiple records per subject in ADSL


General:Reference Documents

• Documents to use when creating standard analysis data

– Analysis Data Model and the ADaM Implementation Guide (www.CDISC.org)

– FDA Study Data Specifications Document (http://www.fda.gov/downloads/ForIndustry/DataStandards/StudyDataStandards/UCM199599.pdf)

• Implications


General:Splitting Large datasets

• Quotes from CDER document– “The size of the LB domain is often quite large and can

exceed the reviewers’ ability to open the file using standard-issue computers. This size issue can be addressed by splitting the large LB dataset into smaller data sets according to LBCAT and LBSCAT, using LBCAT for initial splitting.”

– “Sponsors should submit these smaller files in addition to the larger non-split standard LB domain file. Individual file size up to 400 megabytes is usually fine; however, it is recommended to confirm this with the review division.”

• Implications– This is described specifically for SDTM LB– Applicable to other datasets, even ADaM


ADaM Content:Coded and Imputed Data

• Quotes from the CDER document– “Generally, no numerically coded variables should be

submitted as part of the SDTM datasets.” – “SDTM should not include any imputed data. If there is a

need for data imputations, this should occur in an analysis dataset, and the relevant supporting documentation to explain the imputation methods must be provided.”

• Implications– This work should be done in ADaM– Be sure to include documentation


ADaM Content:Expected Analysis Datasets

• Quotes from the CDER document– “All submissions containing standard data are expected to

contain an ADSL file for each study.”– “Sponsors must submit analysis datasets with their

application to support key efficacy and safety analyses. Additionally, it is important to remember that SDTM datasets do not have core variables (such as demographic and population variables) repeated across the different domains. The need for such duplication of core variables across domains can be fulfilled through their inclusion in the corresponding analysis datasets.”

• Implications– Plan to always create ADSL + datasets for key analyses– Other analysis datasets are optional


ADaM Content:Baseline Variables needed in ADSL

• Quotes from the CDER document– “In addition to the variables specified for ADSL in the ADaM

Implementation Guide, it is expected that the sponsor will include multiple additional variables representing various important baseline patient characteristics.”

• Implications– Which baseline characteristics are important is study-

specific

– ADSL dataset specs will differ by study

– We can use study documentation and sponsor input to determine which additional variables to include


Traceability:Tracing ADaM back to SDTM

• Quotes from the CDER document– “Analysis datasets should be derivable from the SDTM

datasets”

• Implications– All our ADaM variable specs should point back to SDTM

• Possibly via other ADaM variables– No non-SDTM source variable should be used– Ensure USUBJID is consistent across the study

• Inconsistency was noted as a common error– Copy SDTM variables for traceability as needed

• --SEQ, VISIT, *DTC, etc.


Traceability:Consistency across all Datasets

• Quotes from the CDER document– “An individual subject should have the exact same unique

identifier across all datasets, including SDTM and ADaM.”– “Improper implementation of the USUBJID variable is a

common error that is seen with many applications, and often requires sponsors to re-submit their data.”

• Implications– Watch for leading or trailing spaces, zeros, etc.– ADaM Compliance Check #53 will catch this


Traceability:Permissible Variables Expected in SDTM

• Quotes from the CDER document– “Examples of some of the Permissible variables in SDTM

that CDER expects to see include:” • Baseline flags• EPOCH designators• --DY and STDY variables

• Implications– If we don’t see these variables in our SDTM data, we

should suggest they be added

– Copy the baseline flag from SDTM instead of deriving• Exception: when a different/more complicated derivation

is needed than was done in SDTM


Traceability:New Required & Expected SDTM Variables

• Quotes from the CDER document– “A treatment-emergent flag should be included in AE to

indicate if the event was or was not treatment emergent, as determined by the sponsor and as used in the sponsor’s primary adverse event analyses.”

– “…sponsors should refer to the Amendment 1 to SDTM V1.2 located at the following CDISC.org site http://www.cdisc.org/sdtm .” ... “Unless otherwise instructed by a division, these represent CDER-desired changes that sponsors should account for.”

• Implications– If we don’t see these new variables in our SDTM data, we

should suggest they be added– Variables should be copied to appropriate ADaM datasets

rather than derived


Traceability:Derivation of --STDY in SDTM

• Quotes from the CDER document– “--STDY should be calculated based on first treatment date.”

• Implications– Check whether this derivation is appropriate for use in

analysis– Might need to derive study day rather than copy from SDTM


Traceability:SDTM SUPPQUAL Vars that support Key Analyses

• Quotes from the CDER document– “Discussion needs to occur if the sponsor intends to include

important variables (that support key analyses) in the SUPPQUAL datasets. For clinical trial data in SDTM, one way to deal with this issue for important data elements that are likely to be needed to support review work, is to ensure that analysis datasets include these and other relevant data elements. However, these data elements should not then be excluded from SUPPQUAL, since there is a need to maintain traceability from ADaM back to SDTM.”

• Implications– Ensure that any reference to variables in SUPPQUAL be

clear and explicit for reviewers


Integration:Common Dictionaries across a Submission

• Quotes from the CDER document– “It is expected that the Adverse Event dataset for the

Integrated Summary of Safety include MedDRA Preferred Terms from a single version of MedDRA.”

– “…reviewers often want to analyze adverse events across trials, including the use of Standardised MedDRA Queries”

– It is expected that common dictionaries are used across trials and throughout the submission for each of the following: adverse events, concomitant medications, procedures, indications, study drug names, and medical history.”

• Implications– Check to see that this was done in SDTM– If not, the sponsor will need to decide how to describe in

documentation (such as Reviewers Guide)


Integration:Multiple Records per Subject in ADSL

• Quotes from the CDER document– “In the DM domain, each subject should have only one

single record per study. Integrated summaries may contain more than one record per unique subject in the case that an individual subject was enrolled in more than one study.”

• Implications– If we know that the same subject was in multiple studies

within a submission, this must be documented– Suggests that integration be done at the SDTM-level and not

directly from ADaM


Implementation

• FDA CDER– This document and the referenced SDTM V3.12 Amendment

are in draft form and not requirements– Clear that this is what reviewers want

• We should try to implement

• FDA CBER– Nothing official (yet)– Agree in general with CDER’s statements

• ADaM documents may need some revision– Nothing contradicts current ADaM document– We can start implementing now