1 / 28

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

niel
Download Presentation

Implementation of CDISC at BI – Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

  4. 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

  5. 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

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

  7. 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

  8. 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

  9. 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

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

  11. 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

  12. 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

  13. 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)

  14. 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)

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

  16. 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

  17. 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

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

  19. 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

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

  21. 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)

  22. I. Pooling Identifiers / Keys

  23. 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

  24. 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, …)

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

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

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

  28. 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

More Related