AZ CDISC Implementation

Transcription

1 AZ CDISC Implementation A brief history of CDISC implementation Stephen Harrison

2 Overview Background CDISC Implementation Strategy First steps Business as usual ADaM or RDB? Lessons learned Summary 2

3 Background Seven R&D sites all operating in their own environments Creating and maintaining similar tools across the R&D sites Continuous duplication of effort across regions 3

4 A&RT Initiative Project initiation April 2003 Objective: Harmonise the A&R process and environment across ALL R&D sites within AZ Multiple workstreams looking at technology, process and standards Reporting Database (RDB) w/stream Deliver standardized reusable code or macros to automate production of analysis and report ready datasets 4

5 Data Flow Process CRFs Module Package RAW Data Analysis Datasets/ RDB CSR/ HLD Output Previous data flow process was a simple route from existing CRFs to Clinical Study Reports/Higher Level Document outputs Reporting Database is created directly from the Module Package Remit of project was to use existing internal data standards Opportunity to implement CDISC standards 5

6 CDISC Implementation Strategy CRFs Module Package RAW Data Analysis Datasets/ RDB CSR/ HLD Output SDTM RDB completely described in terms of SDTM source good for reviewer No need to construct SDTM at the end of the process 6

7 CDISC Implementation Strategy CRFs Module Package RAW Data Analysis Datasets/ RDB CSR/ HLD Output SDTM RDB completely described in terms of SDTM source good for reviewer No need to construct SDTM at the end of the process Linear process fulfils the requirement of traceability 7

8 Longer term strategy CRFs Module Package RAW Data Analysis Datasets/ RDB CSR/ HLD Output New CRFs/ CDASH SDTM Modified CRFs Underlying RAW data standards are SDTM friendly Transformation process is simplified CDASH - Clinical Data Acquisition Standards Harmonization 8

9 Longer term strategy CRFs Module Package RAW Data Analysis Datasets/ RDB CSR/ HLD Output New CRFs/ CDASH SDTM ADaM ADaM Adopt ADaM model, replacing internal data standards Utilise industry standard transformation and derivation processes 9

10 First steps Global team set up August 2005 to specify AZ business rules Application of SDTM Implementation Guide v3.1.1 from an AZ point of view Two team members also part of CDISC SDS team Inside track to SDTM Scope - all corporate and TA standard modules (>200) Mapping exercise took nearly 18 months to complete! 10

11 11 Manual mapping document

12 Business as usual Web Interface developed Metadata driven process RAW to SDTM and SDTM to RDB mapping function Inherit Corporate data standards and maps down to project or study level Metadata used by code builder to create executable code 12

13 RAW Data Metadata Windows CSV file A&RT Web Interface Project PMPL Dataset Variables Import A&RT Application Database Datasets Variables Study Data Standards Dataset Variables 13

14 Standards and Reuse of Code Corporate Data standards Mappings Locked dataset definitions Locked Corporate map Therapy Area Data standards Mappings Locked dataset definitions Locked TA map Project Data standards Mappings Locked dataset definitions Locked Project map Study Data standards Mappings 14

15 Inheritance SDTM RAW Metadata Corporate mapping SDTM Metadata Corporate DEM AELOG HISM DM AE MH TA (Respiratory) PF CF PULM RESPHIS DEM AELOG Project PULM RESPHIS Project DM AE MH PF CF Study 1 Study 2 Study 1 Study 2 DEM AELOG PULM DEM AELOG RESP HIS DM PF AE DM AE CF MH 15

16 16 Example RAW SDTM map

17 17 Define Simple Mapping

18 18 Define Macro Mapping

19 19 Transposition Groups

20 A&RT Mapping Process Create Mapping Metadata RAW SDTM Create Mapping Metadata SDTM RDB Import RAW Data Metadata A&RT Application Database Web Interface (Oracle) Program Builder UNIX (SAS) SAS code SAS code Execute job Execute job Load RAW Data RAW Database SDTM Database Reporting Database 20

21 ADaM or RDB? Well established reporting requirements AZ Reporting Database standards defined and in use before CDISC considered Perception that ADaM model still quite unstable and subject to significant change Unlike SDTM, no regulatory pressure to implement ADaM 21

22 Reporting Database WBDC Study Database (RAW Data) LAB Mapping to SDTM Reporting Database Superset New Dataset CRO AMOS RAW Module Package Datasets SDTM Data Domains Supplemental Qualifiers Unaltered Source Data in SDTM format Supplemental Qualifiers Derived Observations Derived Variables + Key ID Variables Derived Variables Etc GRand R_AE R_DM R_VS Etc. RD_xx RH_xx Etc. 22

23 Reporting Datasets (R_) Datasets must remain fundamentally unchanged from the SDTM source data. An R_ dataset is a superset of the SDTM dataset SDTM RDB VS SuppVS VS Observations SuppVS Variables R_VS (Superset) Original SDTM dataset name retained, but prefixed with R_ All information from SUPP-- datasets re-attached to parent RDB dataset 23

24 RDB General Conventions All reporting must take place directly from Reporting Database defined at study level All variables used for reporting must be created in relevant reporting dataset Subject datasets must have at least 1 observation per randomized subject All SDTM data must be present in Reporting Database Original SDTM data cannot be amended, but new variables or observations can be created as needed (e.g., imputing dates) All naming conventions defined by SDTM must be followed when generating additional variables 24

25 RDB Common Dataset Features Datasets taken from source database name prefixed with R_ (e.g., DM becomes R_DM) New derived datasets name prefixed with RD_ (e.g., RD_SUBJ) Transposed datasets name prefixed with RH_ (e.g., R_LB becomes RH_LB) Datasets must contain Key variables to uniquely identify every observation Duplication of variables across multiple datasets should be avoided (except for Key and Cross variables) Duplication of source (SDTM) variables should be avoided Variables defined at a higher level must not have attributes changed, except in the following circumstances: Length may be increased Algorithm may be project-specific 25

26 RDB Use of Codes and Decodes Historically, codes and decodes used widely Associated using SAS formats Loses all meaning outside of SAS SDTM does not use codes and decodes Variables defined using explicit text values to describe observations Clear, unambiguous and interpretable irrespective of the tools or software used RDB based on SDTM Codes and decodes not used in final reporting datasets 26

27 Transposed Datasets RAW datasets may be transposed to contain re-structured RAW data (e.g., RH_dataset = horizontal structure, RV_dataset = vertical) Normally only considered for Findings domains Original dataset must still exist as R_dataset May make reporting easier (e.g., lab parameters reported as columns) 27

28 Transposed Datasets Carefully consider whether transposed data is essential and/or appropriate Duplicates data Variable names driven by --TESTCD can be meaningless, e.g.,: Unique subject Identifier Visit name Alanine Aminotranferase (ukat/l) Albumin (g/l) Alkaline Phosphotase (ukat/l) USUBJID VISIT L01101 L01118 L01104 L01102 Aspartate Aminotranferase (ukat/l) 28 Significant loss of information e.g., original results, units, reference ranges, analysis flags, etc. Contravenes CDISC SDTM convention to store units as a separate variable qualifier to the test result

29 29 Example SDTM to RDB map

30 Lessons learned Mapping takes a lot of effort! Ambiguity in guidance Individual opinions and interpretations Get your conventions right Often had to revisit decisions as experience grew Big differences between CRF and SDTM standards: Purpose: data collection vs. data storage Coding: codes vs. text (e.g., 1, 2, 3 vs. mild, moderate, severe) Structure: horizontal vs. vertical SDTM IG v3.1.2 a big improvement Introduction of Clinical Findings (CF) domain really helped with many difficult mappings 30

31 Changes for SDTM IG v3.1.2 CF General Observation Classes Special Purpose Datasets Interventions Events Findings Demographics Clinical Findings (CF) Domain Findings about Events or Interventions that don t fit in SDTM domain variables for those classes CFOBJ (Object of Measurement): Event or Intervention that is the subject of the test evaluation Mandatory, but won t necessarily have a parent record in another domain Comments Related Records Supplemental Qualifiers Trial Design 31

32 Changes for SDTM IG v3.1.2 CF MHCAT MHSTDTC MHTERM MHOCCUR MHPRESP 32

33 Changes for SDTM IG v3.1.2 CF CFCAT CFTESTCD = OCCUR CFORRES = answer provided in checkbox CFOBJ 33

34 Changes for SDTM IG v3.1.2 CF CFCAT CFORRES 34 CFOBJ CFTEST

35 Changes for SDTM IG v3.1.2 CF Example Row USUBJID CFSEQ CFOBJ CFTEST CFTESTCD CFDTC 1 D HYPERTENSION OCCURRENCE OCCUR D D D (continued) MYOCARDIAL INFARCTION MYOCARDIAL INFARCTION MYOCARDIAL INFARCTION OCCURRENCE OCCUR DATE OF MOST RECENT MI MY_LDAT NUMBER OF MI MYNO Row USUBJID VISITNUM CFORRES CFSTRESC CFCAT 35 1 D CURRENT CURRENT 2 D PAST PAST 3 D D SPECIFIC CV MEDICAL AND SURGICAL HISTORY SPECIFIC CV MEDICAL AND SURGICAL HISTORY SPECIFIC CV MEDICAL AND SURGICAL HISTORY SPECIFIC CV MEDICAL AND SURGICAL HISTORY

36 Summary CDISC Implementation is a huge task AZ strategy allows for step-wise implementation CDASH ADaM Mapping tool really assists process Easy inheritance Reuse of standards and code SDTM IG v3.1.2 big improvement 36

37 37 Questions and Answers

38 38 Thank You