Implementing CDASH Standards Into Data Collection and Database Design. Robert Stemplinger ICON Clinical Research

Transcription

1 Implementing CDASH Standards Into Data Collection and Database Design Robert Stemplinger ICON Clinical Research 1

2 Agenda Reasons for Using CDASH Project Outline Implementation Discussion of Results

3 Reasons for Using CDASH

4 Why CDASH? Desire to streamline / standardize CRF library and database structures Develop internal standard as well as maintain sponsor specific standards Internal Standard Started with SDTM / SDTM Aware Migrated to CDASH CRO Industry wide standard facilitated adoption as internal standard

5 Why CDASH? (2) Clinical Database SDTM standards to the extent possible Extract Data incorporating third party data: Labs, ECG, etc. (restructuring when necessary) Statistical Analysis Plan CDASH CT C D I S C SDTM ADaM CT CT TLGs SDTM, ADaM, define.xml, TLGs to Client and/or FDA define.xml define.xml

6 Benefits of CDASH Push standardization toward the beginning of the clinical trial process, have those standards propagate through to the end Standard templates reduce time / resources required for CRF/eCRF and database development Considerably less remapping of raw data structures to SDTM 6

7 Project Outline

8 Implementation Team CRF Design (CRFD) CRF/eCRF design, CRF/eCRF creation, CDASH expertise Data Management (DM) CRF design, database design Database Administration (DBA) Database design, database creation Data Integration and Standardization (DIS) CDASH expertise, SDTM expertise, Controlled Terminology expertise

9 Implementation Package Platforms Supported: InForm, RAVE, OC/RDC, OC Deliverables CRF CRF Completion Guidelines / Help text Database Structures Data Handling Conventions Data Validation Specification / Edits Transformations / Mapping to SDTM Standard Templates / Modules Validation vested at the study level

10 Implementation Process ADMIN Maintain Standards Documentation CRFD Design CRF Module DBA Build Database Modules Program Edit Checks DM Create DHC & DVS DIS Annotate Module to SDTM Map/ Program to SDTM

11 Implementation

12 Implementation Challenges Determining the balance between use in the field versus hard standard Getting people involved early in the process / thinking about the end of the process Clinicians Statistician: SAP Programmers: visualize programming issues from CRF/eCRF Limited to 16 Standard Domains Sponsor/Therapeutic Domains

13 Implementation Challenges (2) CDASH Best Practices (section 3.4 of CDASH v1.0) Recommendations Comments, Inclusion/Exclusion Criteria, Physical Examination, Protocol Deviations Core Designations Highly recommended, Recommended/Conditional, Optional What to include / adhere to?

14 Implementation Challenges (3) CDASH Best Practices Adopt Best Practices Recommendations Comments, Inclusion/Exclusion Criteria, Physical Examination, Protocol Deviations Adopt Recommendations Core Designations Highly recommended, Recommended/Conditional, Optional Incorporate highly recommended and recommended/conditional fields Incorporate optional fields as needed

15 Implementation Challenges (4) Terminology Apply controlled terminology to CRF or map CRF text to controlled terminology in the SDTM data sets Is controlled terminology usable in the field? Apply to CRF

16 CRF Development Core team comprised of DM, DB Programming, DIS, CRF Design Clinical / Biostatistics included as needed Six month duration Paper / EDC layouts similar Navigation text added to EDC screen layouts Did not use Data Collection Field text from CDASH to describe field Handful of domains required more than one standard template DM, IE Optional templates created for a handful of domains CO, IE, PE, DV

17 CRF Development Issues DM MH SU SC Subject Initials, AGE - EU Data Protection / Privacy Multiple Iterations / Versions No verbatim Description text, only body systems No dates Disagreement on how best to implement verbatim text versus pre-defined text Difficult to gain consensus on what should appear on the form

18 CRF Development Issues (2) DM Subject Initials, AGE - EU Data Protection / Privacy Regional Standards MH Multiple Iterations / Versions No verbatim Description text, only body systems No dates Settled on form with body systems and verbatim Description text SU Disagreement on how best to implement verbatim text versus predefined text Decision to implement at study level SC Difficult to gain consensus on what should appear on the form Did not implement

19

20

21 CRF Completion Guidelines / Help Text Used CDASH documentation in conjunction with existing standards Modified per study requirements

22 Database Development Core team comprised of DM, DB Programming Three month duration Did not use Data Collection Field text from CDASH to describe variables Implemented CDASH recommended variable names Defined very simplistic naming conventions for additional text fields required for EDC systems Utilized standard SDTM specification template to populate other variable attributes Utilized data dictionaries, elements, DVGs to attach controlled terminology

23 Database Development Issues No major implementation issues!

24 Table Name Table Description Target Variable Target Label Data Type Length DM_STD Demography STUDYID Protocol/Study Identifier $ 200 DM_STD Demography SITEID Site Identifier $ 200 DM_STD Demography SUBJID Subject Identifier $ 200 DM_STD Demography VISIT Visit Name $ 200 DM_STD Demography VISITNUM Visit Number BEST 8 DM_STD Demography VISDAT Visit Date DATE 8 DM_STD Demography VISDATC Visit Date (char) $ 200 DM_STD Demography INIT Subject Initials $ 200 DM_STD Demography DSSTDAT Consent Date DATE 8 DM_STD Demography DSSTDATC Consent Date (char) $ 200 DM_STD Demography BRTHDAT Date of Birth DATE 8 DM_STD Demography BRTHDATC Date of Birth (char) $ 200 DM_STD Demography AGE Age BEST 8 DM_STD Demography SEX Sex $ 200 DM_STD Demography SEX_C Sex (code) $ 200 DM_STD Demography ETHNIC Ethnicity $ 200 DM_STD Demography ETHNIC_C Ethnicity (code) $ 200 DM_STD Demography S_ETHNIC Other Ethnic Group $ 200 DM_STD Demography RACE Race $ 200 DM_STD Demography RACE_C Race (code) $ 200

25 Discussion of Results

26 Development Results Anecdotal Positive Don t have to start from scratch / copy from one study to the next Metrics Four studies All EDC ~10-20% reduction in number of hours required to develop CRF and database structures as compared to four similar studies put into production without the use of these standard structures

27 Development Results (2) Deliverable Average Hours to Create Deliverables (n=4) Non-CDASH Standards (hrs) CDASH Standards (hrs) CRF/eCRF Database Edit Checks

28 Downstream Results Anecdotal Positive Much less manipulation of raw data structures Metrics Four studies All EDC platforms Limited implementation of controlled terminology ~32% reduction in number of hours required to create SDTM compliant data sets as compared to four similar studies put into production without the use of these standard structures

29 Downstream Results (2) Deliverable Average Hours to Create SDTM Data Sets (n=4) Non-CDASH Standards (hrs) CDASH Standards (hrs) SDTM Data Sets

30 Future Enhancements / Challenges Additional CDASH domains CDASH specific terminology Protocol Representation Model Increase number of sponsors who utilize the standard structures

31 Strength through collaboration. 31