1

PhUSE CDASH2RFD TCMay 31, 2013

Gary Walker, QuintilesRhonda Facile, CDISC

© CDISC 2013

Slide Number One

Agenda

• The need for CRF Standards• Background• Approach• Current Deliverables• Q&A

2

© CDISC 2013

CRFs Without Standards (CDASH)

© CDISC 2013

Data Without Standards…

ID GENDER

A1 Male

A2 Male

A3 Female

A4 Female

A5 Male

4

SUBJID SEX

0001 M

0002 F

0003 F

0004 M

0005 F

USUBID SEX

00011 0

00012 1

00013 1

00014 0

00015 1

PTID GENDER

0001 1

0002 1

0003 2

0004 2

0005 1

Study #2 – dmg.xpt

Study #3 – axd222.xpt

Study #4 – dmgph.xpt

Name for Subject ID is never the

same

Name for demography

dataset is variable???

Is Sex Male or Female, M or F, 1 or 2?

Gender or Sex, what will

this study use?

Adapted from slide courtesy of Armando Oliva, M.D. and Amy Malla, FDA

Study #1 – demo.xpt

© CDISC 2013

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

7

Catalyst

• FDA CRITICAL PATH INITIATIVE: STREAMLINING CLINICAL TRIALS

Creating Innovative and Efficient Clinical Trials and Improved Clinical Endpoints

45. Consensus on Standards for Case ReportForms. Clinical trial data collection, analysis, andsubmission can be inefficient and unnecessarilyexpensive. A wide array of different forms andformats are used to collect clinical trial information,and most data are submitted to the FDA on paper.Differences in case report forms across sponsors andtrials creates opportunities for confusion and error.Standardization of the look and feel of case reportforms could reduce these inefficiencies and also helpaccelerate progress toward electronic data captureand submission.

“Innovation/Stagnation: Challenge and Opportunity on the Critical Path to New Medical Products”, Critical Path Opportunities List, March 2006, page L-10.

CDASH Project Snapshot

• 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

• 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

8

CDASH Project Snapshot

• 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

• 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 Sub-teams with participation of ~50 team members

9

© CDISC 2013

Purpose of CDASH

• Initial scope limited to most commonly collected data• These CRF standards apply across most therapeutic areas and

phases of clinical development (I-IV)

Develop CRF content standards for a basic set of global industry-wide CRF fields to support clinical research

Maximize re-use of data, CRFs, programming, etc.

Increase transparency and traceability in the data

Support data repository and data sharing

• CDASH used as a content standard to harvest data from electronic health records (Healthcare Link)

Support integrating research into clinical care workflow

10

Section 1.1 of CDASH v1.1

© CDISC 2013 11

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 CDASH V 1.1 2010

18 Domains

UG V1.0 published in 2012

Mapping to SDTMCRF ExamplesCDASH in ODM

Clinical Data Acquisition Standards Harmonization:

Basic Data Collection Fields for Case Report Forms

Prepared by the CDISC CDASH Core and Domain Teams

Revision History

Date Version Summary of Changes

2008-08-22 Final Draft 1.0 NA

CDASH Standards

12

© CDISC 2013

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

SDTM Variable Name

OR CDASH Variable Name

BRIDG

Mapping Defines the Data

collection field

Instructions for the

clinical site on how to enter data

on the CRF. Includes

controlled terminolog

y

Information/rationale and instructions on how to implement

the CRF data collection

fields

Designations

HR

Rec/Cond

Optional

© CDISC 2013

Overview of CDASH Tables

Domain tables contain most common fields in clinical trials

• Supplement therapeutic area-specific fields according to protocol

Standard domains do not contain everything

Domain tables are arranged in alphabetical order

• Data collection fields are presented in the domain tables similar to the order found on a CRF

• Example CRFs are in the CDASH UG

CRF layout is not part of scope

14

Section 4.3 of CDASH v1.1

© CDISC 2013

General Notes

• Applies to both paper CRFs and eCRFs• If something only applies to one, it will be noted in

the standardCDASH

• What is on the CRF• Date concomitant medication was started“Fields”

• What is in the database• CMSTDAT, or CMSTDY, CMSTMO, CMSTYR,

etc.“Variables”

• Encompasses investigational products, devices, study drug, etc.“Study treatment”

Section 1.2.1 of CDASH v1.1

© CDISC 2013

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

• Tick box, Check box, Code list, Pick-list, Radio buttons, Dropdown list

These are all interchangeable ways to describe a pre-defined list of response choices on the CRF

16

Section 1.2.1 of CDASH v1.1

© CDISC 2013

CDASH Standard Document Contents

• Header data elements presented first• CRF domains (topics) arranged alphabetically

Documents the defined standard for data collection, organized by CRF “topic”

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

17

Section 1.2 of CDASH v1.1

© CDISC 2013

CDASH User Guide

18

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.

© CDISC 2013

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

19

© CDISC 2013

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

20

© CDISC 2013

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)

21

© CDISC 2013

CDASH Overview

Q&A

22