PhUSE CDASH2RFD TC
May 31, 2013
Gary Walker, Quintiles
Rhonda Facile, CDISC
1
Slide Number One
Agenda
•
•
•
•
•
The need for CRF Standards
Background
Approach
Current Deliverables
Q&A
© CDISC 2013
2
CRFs Without Standards (CDASH)
© CDISC 2013
Data Without Standards…
Name for
Subject ID
is never the
same
Study #1 – demo.xpt
SUBJID
SEX
0001
M
0002
0003
Study #2 – dmg.xpt
ID
GENDER
A1
Male
A2
Male
A3
Female
A4
Female
A5
Male
F
F
Study #4 – dmgph.xpt
0004
M
PTID
GENDER
0005
F
0001
1
0002
1
0003
2
0004
2
0005
1
Is Sex Male or Female,
M or F, 1 or 2?
Name for
demography
dataset is
variable???
Study #3 – axd222.xpt
USUBID
SEX
00011
0
00012
1
00013
1
00014
0
00015
1
Gender or Sex,
what will
this study use?
Adapted from slide courtesy of Armando Oliva, M.D. and Amy Malla, FDA
© CDISC 2013
4
Data Collection With CDASH (paper)
© CDISC 2013
Basic Concepts of CDASH
• Minimal ‘core’ dataset for clinical research
• Standardize the questions/fields on CRFs
• Standardize the variables and harmonize with
SDTM (CDASH is a subset of SDTM)
• Collect data using standard CDISC controlled
terminology that maps into SDTM
• Implementation help
 Best Practice recommendations
 Implementation recommendations
http://www.cdisc.org/cdash
© CDISC 2013
Catalyst
• FDA CRITICAL PATH INITIATIVE:
STREAMLINING CLINICAL TRIALS
 Creating Innovative and Efficient Clinical Trials and Improved
Clinical Endpoints
 45. Consensus on Standards for Case Report
Forms. Clinical trial data collection, analysis, and
submission can be inefficient and unnecessarily
expensive. A wide array of different forms and
formats are used to collect clinical trial information,
and most data are submitted to the FDA on paper.
Differences in case report forms across sponsors and
trials creates opportunities for confusion and error.
Standardization of the look and feel of case report
forms could reduce these inefficiencies and also help
accelerate progress toward electronic data capture
and submission.
“Innovation/Stagnation: Challenge and Opportunity on the Critical Path to New Medical Products”,
Critical Path Opportunities List, March 2006, page L-10.
7
CDASH Project Snapshot
• Streamlines data collection at
investigative sites - addresses
Critical Path Opportunity #45
• Continuation of ACRO’s
Initiative
• Started October 2006
• Supported by a collaborative
group of 17 organizations
• Initial Core Team of 16 members
managed
 11 working groups
 Composed of between 8-40
volunteers
• 16 (+2) Safety data domains
developed
• Consolidated document posted
for public review in May 2008
• Received over 1800 comments
from 46 companies, institutions
and agencies.
• All 3 ICH regions were
represented in the public
comment process
 US
 Europe
 Japan
• V1.0 published in October 2008
8
CDASH Project Snapshot
• Version 1.1 published January
2010 to address




New data elements added
A few corrections
Question Text and Prompt
Conformance Rules
• CDASH and the analogous NCI
CRFs are being harmonized
• Current Leadership Team
manages several CDASH Subteams with participation of ~50
team members
• CDASH User Guide became
available to members in 2012,
including
 User Guide documentation
 CDASH content in ODM
 CDASH example CRF library
• Therapeutic Area CRFs are
being developed, including
 Alzheimers
 Cardiovascular
 Oncology
• CDASH guidelines to address
regulatory requirements (DILI,
E2B) are being developed
9
Section 1.1 of CDASH v1.1
Purpose of CDASH
Develop CRF content standards for a basic set of global
industry-wide CRF fields to support clinical research
• Initial scope limited to most commonly collected data
• These CRF standards apply across most therapeutic areas and
phases of clinical development (I-IV)
Maximize re-use of data, CRFs, programming, etc.
Increase transparency and traceability in the data
Support data repository and data sharing
Support integrating research into clinical care workflow
• CDASH used as a content standard to harvest data from
electronic health records (Healthcare Link)
© CDISC 2013
10
Principles
 Ensure that SDTM “required” elements are
addressed directly or indirectly
 Be “standard” but flexible to allow customization
within defined limits
 Focus on CRF Content, not CRF Layout
 Limit variables to required and necessary
 Comply with regulatory requirements
 Reduce redundancies
 Facilitate use of standards by all users
 Be appropriate for use both pre and post approval
studies
 Allow consistent and efficient data
collection/storage/transmission and analysis
© CDISC 2013
11
CDASH Standards
CDISC CDASH
V 1.1 2010
18 Domains
Clinical Data Acquisition Standards
Harmonization:
Basic Data Collection Fields for Case Report
Forms
Prepared by the CDISC CDASH Core and Domain Teams
UG V1.0 published in 2012
Mapping to SDTM
CRF Examples
CDASH in ODM
Revision History
Date
2008-08-22
Version
Final Draft 1.0
Summary of Changes
NA
12
Metadata Tables
Full question
text for the
data
collection
field. Either
question text
or prompt can
be used on
the CRF
Short prompt
for the data
collection
field; could
be used as
the CRF
label
BRIDG
Mapping
SDTM
Variable
Name
OR CDASH
Variable
Name
© CDISC 2013
Defines the
Data
collection
field
Instructions
for the
clinical site
on how to
enter data
on the CRF.
Includes
controlled
terminolog
y
Information/r
ationale and
instructions
on how to
implement
the CRF data
collection
fields
Designations
HR
Rec/Cond
Optional
Section 4.3 of CDASH v1.1
Overview of CDASH Tables
Domain tables contain most common fields in clinical
trials
Standard domains do not contain everything
• Supplement therapeutic area-specific fields according to
protocol
Domain tables are arranged in alphabetical order
CRF layout is not part of scope
• Data collection fields are presented in the domain tables
similar to the order found on a CRF
• Example CRFs are in the CDASH UG
© CDISC 2013
14
Section 1.2.1 of CDASH v1.1
General Notes
CDASH
• Applies to both paper CRFs and eCRFs
• If something only applies to one, it will be
noted in the standard
“Fields”
• What is on the CRF
• Date concomitant medication was started
“Variables”
“Study treatment”
© CDISC 2013
• What is in the database
• CMSTDAT, or CMSTDY, CMSTMO, CMSTYR,
etc.
• Encompasses investigational products,
devices, study drug, etc.
Section 1.2.1 of CDASH v1.1
Data collection mechanisms
CDASH is system-independent
When a CRF restricts responses to a set list of choices,
different collection systems may handle it differently
These are all interchangeable ways to describe a predefined list of response choices on the CRF
• Tick box, Check box, Code list, Pick-list, Radio buttons, Dropdown
list
© CDISC 2013
16
Section 1.2 of CDASH v1.1
CDASH Standard Document
Contents
Documents the defined standard for data collection,
organized by CRF “topic”
• Header data elements presented first
• CRF domains (topics) arranged alphabetically
Best Practices on CRF design along with FAQs
Provides references to regulatory documents that
were considered during CDASH creation
Describes how CDASH relates to other CDISC
standards
© CDISC 2013
17
CDASH User Guide
Clinical Data Acquisition
Standards Harmonization (CDASH)
User Guide
Prepared by:
CDISC CDASH Project Team
CDASH_USER GUIDE V1-1.1
© CDISC 2013
Contains
implementation
examples, including
CDASH to SDTM
mappings,
CDASH ODM files and a
library of example CRFs
that have been created
in several different data
collection systems,
including paper
examples.
12 April 2012
18
Core Designations
• Highly Recommended (HR): A data collection
field that must be on the CRF (e.g., a regulatory
requirement)
• Recommended/Conditional (R/C): A data
collection field that should be on a CRF based on
certain conditions (e.g., complete date of birth is
preferred, but may not be allowed in some
regions, AE time should only be captured if there
is another data point with which to compare it)
• Optional (O): A data collection field that is
available for use
© CDISC 2013
19
FAQs
• Yes/No questions are preferred over “check all
that apply” format
• Keep response boxes (Yes/No/NA) in a standard
format consistent across CRFs
• Use unambiguous date format DD-MMM-YYYY
• Create convention to capture Unknown portions of
the date-DO NOT IMPUTE!
• Use 24 hour format for times
• Do not include manually calculated items on the
CRF (e.g. BMI) if the raw data are collected
© CDISC 2013
20
Current CDASH
Subteam Projects
• Development of PK CRF content
• Development of Device CRF content
• Working on update to CDASH 2.0 (new version of
standard)
• Working on update to CDASH UG
• Liaising with TA teams for Alzheimer’s Disease,
Asthma, Diabetes. (Future TA work TBD)
• Looking at development of CDASH Model
• Expanding CRF Library
• Adding Terminology guidance for mandatory
codelists in the next version of CDASH (2.0)
© CDISC 2013
21
CDASH Overview
Q&A
© CDISC 2013
22