Implementation of CDISC at BI – Overview

Implementation of CDISC at BI – Overview CDISC German User Group Meeting Sep 2009 • Dr. Jens Wientges • IBM Global Business Services • Life Sciences / Pharma Consulting

Motivation, Objectives and expected Benefits • System Landscape, Data Flow and Processes • Approach • Real life examples of issues and sponsor defined elements

Implementing CDISC at BI (ICBI) - Motivation • Requests for analyses on substance/project databases SDB/PDB are increasing • need to effective use and exploit clinical data beyond single trials • need to build efficient substance databases • Aharmonized data model based on CDISC allows for • a wider range of standard reporting tools • re-use of standard programs • facilitated familiarization with new trials/projects • higher flexibility in assignments to projects • quicker response to regulatory requests (same view on data) • BI has taken the decision to implement the CDISC data standards to effectively manage, exploit and report clinical data

ICBI - Objectives Corporate wide, Harmonized Clinical Data Structure • Effectual for: - single clinical trials - pooled databases (PDB) • Operational data structure, allowing: - data quality checks - ADS/ADaM generation - Ad hoc statistical analysis • Based on the principles of the CDISC data standards

ICBI - Business Benefits Shown in three categories: • Submission / Regulatory Compliance • Knowledge Generation • Effort & Time Saving

1 ICBI - Business BenefitsSubmission / Regulatory Compliance • Working with a data structure close to the one requested for Submission • Allows traceability from analysis data (ADaM) back to raw data (BI-CDISC and plain SDTM) • allows for semi-automated generation of plain SDTM and define.xml • is a one time effort per submission • is less time consuming • creates no external costs • Having the same view on data as authorities • Increases transparency • Leads to higher efficiency / turn-around time in answering questions  Standardized Data Structure will - further enhance compliance to regulatory requirements - allow more efficient creation of submission package

2 ICBI - Business BenefitsKnowledge Generation Working with one data structure across trials: • Allows easier creation of PDB and pooling of trial data • Leads to effective meta-analyses on project and/or substance level • Increases re-use of standard programs, program templates and views • Supports exchange between OPUs and functions (e.g. PK/PD, PGx, partners, …) • Allows (semi-)automated load, transformation and incorporation of external data from vendors, suppliers, pharmaceutical and collaboration partners • Leads to higher flexibility in assignments to trial & project tasks • Reduces time to answer of internal (various customers, e.g. medical affairs) requests • Reduces time to answer of external (regulatory) questions  Standardized Data Structure will further enhance effective pooling of data and pooled analyses

3 ICBI - Business BenefitsEffort & Time Saving Working with BI-CDISC facilitates downstream processes: • Semi-automated generation of define.xml for SDTM and ADS/ADaM • no review cycles for define.xml generated externally • Same view on data as authorities • increases transparency • results in higher efficiency in answering questions • A higher degree of automation, making use of metadata (CDR) • enables more efficient programming • reduces validation efforts • Reduces effort for creation of standard ADS/ADaM • Standardized Data Structure will - establish a higher level of standardization - further enhance analysis with reduced timelines

Chosen Approach for BI-CDSIC • In line with the recommendations of the SDTM and Analysis Datasets Implementation Expert Team for a CDISC data standards implementation we defined the following cornerstones for our data model: • Define a sponsor specific in-house data-structure (BI-CDISC) and create SDTM and ADaM/ADS in parallel from there • Definition of transformation rulesfrom BI-CDISC to SDTM and from BI-CDISC to ADaM/ADS (but not creating ADS from SDTM) • The data model contains both collected and derived data • The data model will omit RELRECand SUPPQUAL (will only be created upon generation of plain SDTM for submission) • BI-CDISC will make use of the SDTM vocabulary • SDTM-vocabulary defined as variable metadata and controlled terminology, not the SDTM structure • BI-CDISC is defined by metadata and (long-term vision) metadata shall drive the transformations from this BI-CDISC to SDTM and ADaM/ADS. Traceability from SDTM  ADaM is sufficiently granted by including the SEQ variable in CDR and inherit it to SDTM/ADaM and/or metadata defining the various transformation steps

ICBI Data Flow through System Landscape Load from O*C and Transform in CDR (LSH) CDR (LSH) Trial Database / Substance DB O*C Trial Database Submission To FDA Study Setup O*C Export Data Load Transform CDR 1 Pooled Database Transform CDR 2 ADS Dev. Displays Dev. Master Mapping Table Trial specifics  manually partially manually Meta info Trial 1 define.xml Final Report as is no Change no change as is no change SDTM+ as is Transform SDTM SDTM, ADaM, Tables, Listings, Profiles, + Metadata, define.xml ADaM Trial 2 define.xml as is as is no change no change as is no change SDTM+ SDTM Transform ADaM Pool as is define.xml as is SDTM+ SDTM ADaM Pooled DB

Cornerstones of ICBI • There will be no impact on early processeslike study set up, data entry, and user friendliness of RDC. Data cleaning and discrepancy management remains in O*C • ICBI requires a certain upfront (once for each trial)effortfor trial specific transformation to SDTM+ and its QC/validation • Once data are available in the O*C database, they are loaded into LSH. Loading is triggered by a completed Batch Validation session in O*C • After loading the data into LSH, they can be automatically transformed into the SDTM+ structure (Load and transformation steps can be combined in one LSH workflow) • ADS/ADaM will be created from SDTM+ and form the basis for reporting • The submission data sets in plain SDTMare created by sub-setting and restructuring out of SDTM+ (can be automated)

Cornerstones of ICBI • The define.xmlcan be created semi-automaticallytaking the meta data available in LSH thus improving quality (inconsistencies) and timely delivery of final submission data sets • To gather all meta information needed for SDTM, ADS and define.xml a process needs to be implemented to capture the meta information throughout the process (see Module “Meta Data Collection and Master Mapping Table”) • To enable DQRM reporting to be based on SDTM+, the data need to be available in SDTM+ structure early/close to First Patient In • Training would be required for all functions working with the data in LSH. The O*C part of the process would not be effected (Overview training recommended only)

OCViews • T/PSAP • ADS Plan • Protocol • aCRF Overall Approach Mapping Table • SDTM Implementation Guide • CDISC Controlled Terminology BI-DM • BI-DM User Requirements • BI PDB Requirements • BI GLIB CT (formats) • ADaM IG • BI ADS Guideline • Data Quality Requirements

Overall Approach – Trials • Design Data Model based on two trials of indication A • Expand Data Model with two trials of indication B • Proove Data Model (PoC) • Create Pooled Database (PDB) of all four trials • Re-create trial ADS from PDB • Create submission SDTM from PDB

Keys & Relations CT & Formats Overall Approach – Teams Safety Treat/Exposure Lab/Ext. Data Efficacy • One Rep from each Team • One Rep from each Team

Overall Approach – Scope for Teams Study A Study B • O*C Views available for the studies used for mapping • are the starting point for the mapping • are divided up among the groups according to topics • topics are based on logical grouping of SDTM domains • Treat. - Exposure - TD • Efficacy • Safety • Lab - External Data

Using --SEQ… • --SEQ should not be used for any SAS/SQL evaluation • --SEQ is dynamically assigned and might change until a database is locked • If BI-CDISC datasets are created multiple times prior to lock then –-SEQ will be assigned differently whenever rows/observations of data have been added or removed • In different snapshots of the same trial the value of --SEQ will not be consistently applied to common observations • The Keys and Relations team does not consider the above points to be issues, (to maintain consistency in --SEQ would be very difficult / impossible to achieve, with little / no gain)

I. Pooling Identifiers / Keys

ICBI – Interdomain Dependencies • Mappings are often not trivial • BI-CDISC variables should be derived only once and from one single source • Domains have to be created/populated in a defined order

CT Consolidation – LABNM Format • For LABNM (>1000 code/decodes) it was decided to split them out to three variables (LBTESTCD, LBSPEC and LBMETHOD) • In special cases additional variables required (position, fasting status, time, …)

Identified SDTM+ e.g. e.g. e.g. * R – required, B - beneficial

Identified SDTM+ e.g. e.g. * R – required, B - beneficial

Identified SDTM+ e.g. e.g. e.g. * R – required, B - beneficial

Dr. Jens Wientges Mailto: wientges@de.ibm.com Mobile: + 49 160 5826897 Peter Leister Mailto: peter.leister@de.ibm.com Mobile: +49 160 3671761 IBM Global Business Services. • Contacts • Dr. Jens Wientges • Peter Leister

Implementation of CDISC at BI – Overview