Implementing CDASH
Standards Into Data Collection and Database Design
Robert Stemplinger ICON Clinical Research
Agenda
• Reasons for Using CDASH
• Project Outline
• Implementation
• Discussion of Results
Reasons for Using CDASH
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
Why CDASH? (2)
Clinical Database
C D I S C SDTM ADaM
SDTM standards to the extent
possible
Extract Data incorporating third party data:
Labs, ECG, etc.
(restructuring when necessary)
Statistical Analysis Plan
SDTM, ADaM, define.xml,
TLGs to Client and/or FDA
TLGs CDASH
CT CT
CT
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
Project Outline
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
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
Implementation Process
ADMIN
CRFD
DBA
DM
DIS
Design CRF Module
Annotate Module to
SDTM
Build Database
Modules
Create DHC &
DVS
Program Edit Checks
Map/
Program to SDTM Maintain Standards Documentation
Implementation
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
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?
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
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
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
CRF Development Issues
• DM
– Subject Initials, AGE - EU Data Protection / Privacy
• MH
– Multiple Iterations / Versions
• No verbatim Description text, only body systems
• No dates
• SU
– Disagreement on how best to implement verbatim text versus pre-defined text
• SC
– Difficult to gain consensus on what should appear on the form
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 pre- defined text
– Decision to implement at study level
• SC
– Difficult to gain consensus on what should appear on the form – Did not implement
CRF Completion Guidelines / Help Text
• Used CDASH documentation in conjunction with existing standards
• Modified per study requirements
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
Database Development Issues
• No major implementation issues!
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
Discussion of Results
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
Development Results (2)
Average Hours to Create Deliverables (n=4)
Deliverable
Non-CDASH Standards
(hrs)
CDASH Standards
(hrs)
CRF/eCRF 73.25 64.35
Database 194.25 163.25
Edit Checks 253.50 203.21
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
Downstream Results (2)
Average Hours to Create SDTM Data Sets (n=4)
Deliverable
Non-CDASH Standards
(hrs)
CDASH Standards
(hrs)
SDTM Data Sets 89.3 60.1
Future Enhancements / Challenges
• Additional CDASH domains
– CDASH specific terminology
