a practical implementation of adam - cdiscportal.cdisc.org/cdisc user networks/europe/english...

11GLOBAL BIOMETRICS

BiostatisticsClinical Data Management

Epidemiology & Patient Reported OutcomesStatistical Programming and Analysis

Strategic Planning, Operations and Collaborations

A Practical Implementation of ADaM

Chris Price, Roche Products Ltd.

GLOBAL BIOMETRICS Biostatistics

Clinical Data ManagementEpidemiology & Patient Reported Outcomes

Statistical Programming and Analysis Strategic Planning, Operations and Collaborations

Agenda

Project BackgroundADSLTraceabilityAnalysis FlagsMultiple BaselinesSafety Data and Legacy SystemsConclusions

Project Background

Pharma / Biotech Collaboration: Roche and Genentech (pre-merger)New Rheumatoid Arthritis moleculeFour Phase III clinical studies getting startedDifferent proprietary data standards at each companyNeither company had production/filing SDTM or ADaM experienceDecision to use SDTM and ADaM taken November 2007

Project Background - Timelines

SDTM - modelled and programmed during 2008Draft ADaM v2.1 and ADaM IG v1.0 released May 2008ADaM specifications written Q4 2008 using SDTM as the sourceADaM datasets programmed - Q1 2009Tables, Figures and Listing programmed using ADaM -Q2 2009First Study Database Lock - December 2009Final study Database Lock - May 2010Final ADaM v2.1 and ADaM IG v1.0 published December 2009

Project Background - Key Decisions

Used draft versions ADaM v2.1 and ADaM Implementation Guide v1.0

No update to final version for subsequent studiesADaM Basic Data Structure (BDS) only implemented for efficacy data Safety data not mapped to BDS

BDS is unsuitable for occurrence/event based dataProprietary standards already in existence for reportingDecision taken to combine core and suppqual domains and add any required flagsThese were mapped to internal standards for use with the standard internal tools

Project Background - Analysis Requirements

ACR 20/50/70/90Composite endpoint

66/68 Swollen and Tender Joint CountsHealth Assessment Questionnaire (HAQ)ESR/CRPVisual Analogue Scores (VAS)

Disease Activity Score (DAS-28)Composite Endpoint

28 Swollen and Tender Joint CountsESR/CRPVisual Analogue Scores (VAS)

Response Duration

Project Background - Analysis Requirements

Hands and Feet X-Ray EndpointsComposite Endpoints

Erosion ScoresJoint Space Narrowing Scores

Multiple Sensitivity AnalysesDifferent missing data imputations for different parametersDifferent approach to withdrawals and use of rescue medications for different parameters

Multiple Subgroup Analyses

Project Background - Data Flow

SDTM core and suppqual domains

combined, ISO8601 date/times

converted to numeric variables and programmable PVs written before

ADaM programming

ADaM datasets set up as a series of

dependent datasets split by endpoint

Minimum requirement for a ADaM submissionContains all variables important for describing the target population

DemographicsDisease factorsTreatment GroupsOther Relevant Variables

What other relevant variables should be included in this project/study?

Variables included:Demographics and DispositionTreatments and PopulationsStatistical Model covariates (e.g. IVRS stratification factors)Key study dates (e.g. Date of First Rescue Medication)

Variables excluded:Baseline measurements used in subgroups

Some complex derivation performed in later analysis datasetsUse of macros was not felt to be appropriate in this instanceMapped to ADBASE to ensure consistency between datasetsADBASE modelled using BDS

ADBASE

Traceability

Traceability is a “cornerstone” of the ADaM modelRepresented in

Metadata between variables and their sources between analysis results and the analysis datasets

Data pointsBetween analysis observations and their predecessor observations

How practical is data point traceability in real-life?Easy to use --SEQ in simple casesHow to show traceability for second layer parameters?

Traceability

First layer datasetsIndividual observations used in the derivation of a new parameter included in dataset and traced using --SEQ

E.g. Individual Joint Results included in ADJNT for use in calculating total joint counts

Missing data rules implemented using derivation type to flag LOCF observations

E.g. DTYPE used to flag LOCF observations at the individual joint level

Analysis flags to used to flag different types of calculating total scores for use in both analysis and other derivationsFunctional specifications written to be included in define.xmldescribing the derivation

Traceability

Second/Third layer datasetsImmediate predecessor observations included

E.g. Total 66/68 joint counts included from ADJNT in ADACR to derive ACR score

Functional specifications used to facilitate traceability for composite endpoints based on derived parameters

Analysis flags used to identify selected observations based on imputation and rescue rulesNew analysis flags derived for the composite endpoints based on the imputation rules used in the individual parametersParameter Invariance rule interpreted in a way to support clarity

Traceability

Analysis Flags

Analysis flags are conditionally required to identify observations used in one or more analyses

Can be sole identifierOr more usefully in conjunction with other variables

Generic naming convention can cause problems with consistency between studiesCan in some cases form part of the primary key

Missing values are expected as controlled terminology is Y/nullDoes this matter? - Is a primary key necessary in an analysis dataset?Additional sponsor defined variables were added to avoid this issue

Analysis Flags

An observation was created for each analysis flag required

Not necessary as per IG rulesIncreases the size of the datasetSimpler to specify and programSimpler visual review of data and developer checking of programmingClearer metadataAllows for an additional variable so a valid primary key is created

Analysis Flags

Potential pooling issues minimized by using project levels specificationsFlags were set up so have the same meaning across all datasets and the submission

23 different analysis flags needed across all ADaM datasetsANL01FL = LOCF excluding rescue and withdrawal…ANL18FL = Linear Extrapolation…

Cross tabulations included in specifications to show which Analysis flags were created for which parameters

Analysis Flags

Multiple Baselines

Rule 6 from IG“When there is more than one definition of baseline, each additional definition of baseline requires the creation of its own set of rows”BASETYPE is used to identify the baseline definition

Logical approach from a standard design perspectiveMakes building standard reporting tools easierCan massively increase the size of datasets if required for lots of parameters compared to adding new variables

But… If only one parameter required in a large dataset - less data points are added

Adds to the complexity of the dataset

Multiple Baselines

For some Pharmacodynamic Parameters Change from Screening was analysed as well as Change from Baseline

Data was duplicatedObservations for Change from BaselineObservations for Change from ScreeningFor matching parameters and visits AVAL did not change

BASETYPE was additionally required to identify observations for analysis

Analysis flags were used to differentiate between observations within each type of baseline

Multiple Baselines

Safety Data and Legacy Systems

BDS is unsuitable for Occurrence based dataE.g. Adverse Events, Concomitant Medications

ADAE is expected to be released by the ADaM teamExisting internal standard safety reporting tools did not support ADaM structure (or SDTM)Collection and tabulation models are currently being updated internallyConsequently tools are also being updated to work with SDTM and ADaM

Safety Data and Legacy Systems

Flags were added to SDTM datasets where necessary to create Safety Analysis Datasets (SADs)An interim step of converting SDTM to the internal standard was performedStandard Safety Reporting

Programmed using standard toolsNon-standard safety reporting

Additional ADaM datasets created from SADsE.g. Patient Years Exposure

Analyses programmed from SADs

Conclusions

Implementation of ADaM is challenging but possibleBut is legacy mapping any easier?

ADaM is currently an immature standardADaM datasets can become increasingly complex very quicklyThere are currently too many grey areas

Current documentation is insufficient for full scale implementationHopefully the implementation examples of ADAE and ADTTE will help when released

A sponsor introducing a wide scale implementation would be taking a big risk

a practical implementation of adam - cdiscportal.cdisc.org/cdisc user networks/europe/english...

Documents

mayo-portland adaptability inventory (mpai-4) -...

building and using practical agent applications sri...

edc as central data repository - cdiscportal.cdisc.org/cdisc...

preoperative assessment in private practical pointers for...

tutorial for module by1101 practical revision: mcq adam kane...

adam klimas adam klimas adam klimas 791 34...

do recommendation 1a? comment - auda · adam michael every...

introduction to define - cdiscportal.cdisc.org/cdisc user...

legal writing for the “real world”: a practical guide...

esther: adam: esther: adam: esther: adam: esther

practical tips for digital implementation in small...

from adam handbook to adam -j

adam - opel deutschland · adam welcher adam passt zu dir?...

opel adam katalog – opel adam broszura – opel adam rok...

ember 2013 - opel-infos.de · opel adam 2...

john troxell, accenture - cdiscportal.cdisc.org/cdisc user...

adam czarnecki, chrp practical examples

ganesh sankaran - cdiscportal.cdisc.org/cdisc user...

ehr integration increasing data efficiencies -...

study data reviewer’s guide - cdiscportal.cdisc.org/cdisc...