1. CDASH Initiative: Status Update
Bay Area CDISC Implementation Network Meeting - May 29, 2008
Rhonda Facile, Project Director, CDISC
Dorothy B. Dorotheo, InterMune
Mark Wheeldon, Formedix

2. Snapshot Overview
CDASH Purpose & Scope
Who Participated in CDASH
How CDASH Developed?
CDASH Domains – Where are we?
CDASH Domains – New Ideas
CDASH Variable Metadata
CDASH Core Designations
Practical Implementation of CDASH within CDISC ODM
CDASH Goals

3. Snapshot
Critical Path Opportunity #45 – Streamline data collection at investigative sites.
Continuation of ACRO’s Initiative
Started October 2006
Supported by a Collaborative Group of 17 organizations
Core team of 15 members manages..
11 working groups
Groups with between 8-40 volunteers
~190 work group volunteers + additional reviewers (both nationally and internationally)
16 Safety data domains developed..
organized in 4 “Packages”
Draft consolidated document now out for public review – April 2008

4. CDASH Purpose & Scope
To develop a set of ‘content standards’ (element name, definition, metadata) for a basic set of global industry-wide data collection fields that support clinical research.
The initial scope - ‘safety data/domains’.
These safety domains cut across all therapeutic areas (TA independent).
Follow CDISC Operating Procedure for Standards Development (COP-001).

5. Who Participated in CDASH?
Team membership:
Statisticians
Medical Monitors/Clinical Scientists
Regulatory Affairs
Drug Safety
Data Managers
Clinical Study Coordinators
Clinical Research Associates
Investigators
Clinical Program Managers
Statistical Programmers
Database programmers
More multi-national input welcome.
Participants in the CDASH Initiative
Other = Academic Research Organizations,
Government (NIH, NCI), Hospitals, Universities.

6. How was CDASH Developed?
Start with Study Data Tabulated Model (SDTM)
Focus on CRF Content, not CRF Layout
Refer to ACRO CRF Samples (where available)
Collect CRF samples
Evaluate commonalities/differences of CRF samples
Document data points included/excluded with justifications

7. How was CDASH Developed?
Agree on basic data collection fields
Map to SDTM
Terminology - proposals shared with the Terminology Team
Write definitions and completion instructions for clinical site and Sponsors
Proceed to the next step in the Consensus Process

8. CDASH Domains – Where we are
Package-1: AE CM DM SC
Started Oct 06
Package 3: DA EX CO DV DS
Started Mar 07
Package-2: IE MH SU PE VS
Started Dec 06
Package-4: LB EG
Started Jul 07
Consensus
(Initial)
Version
Harmon-
ized
Released
(Production)
1.0
Review
TLC
Collaborative
Group OK
Public
Published & Out for Public Review – April 2008

9. CDASH Variable Metadata
Question text for collection on the CRF.
How to
implement
the CRF
data collection variable
Describes the purpose of the data collection field
SDTM-IG conforming variable name
(CDASH
variables shaded)
Aka CRF
Completion Instructions
CDASH Core Designations

10. CDASH Core Designations
Highly Recommended
A data collection field that should be on the CRF (e.g., a regulatory requirement (if applicable)). (e.g. Adverse Event Term)
Recommended/Conditional
A data collection field that should be collected on the CRF for specific cases (may be recorded elsewhere in the CRF or from other data collection sources). (e.g. AE Start Time)
Optional
A data collection field that is available for use if needed. (e.g. Were there any AE Experienced?)
In SDTM, there are also 3 categories, REQUIRED, EXPECTED & PERMISSIBLE
The two standards initiatives do not have same purpose/goal:
SDTM is for submission, and CDASH is for data collection. There is not a one to one match in most cases.
Highly recommended —fields that really need to be collected; basic fields that are or need to be collected on a CRF
Recommended/conditional —collected on the CRF for specific cases e.g. collecting time for precision like in a phase 1 study when patients are confined in the study unit and it is impt. in analysis or it may be derived from other fields…less strong a recommendation
Optional —a fields available for your use if your protocol needs it.

11. CDASH Domain – New Ideas
Physical Examination (PE)
Use PE form to record only whether or not exam was done
Instruct Sites to record,
Baseline Abn.: MH, Targeted MH or Baseline Conditions CRFs.
Post baseline abn. or baseline conditions that worsened on AE CRF
Inclusion/Exclusion (IE)
Use IE form to collect only the criterion or criteria NOT MET for Inclusion/Exclusion criteria

12. CDASH Domain – New Ideas
Protocol Deviations (DV)
Avoid creating a protocol Deviations CRF because this information can often be derived from other CRF domains or system functionalities.
Comments (CO)
Avoid the creation of a General Comments CRF which collects unsolicited comments.

13. “Practical Implementation of Clinical Data Acquisition Standards (CDASH) in the CDISC Operational Data Model”
Mark Wheeldon, CEO, Formedix
Bay Area User Group, 29th May, 2008

14. Who are we? Involved with Standards since 2001
All our solutions are based on Open CDISC Standards
CDISC Products and Consultancy Company
Planning, Preparation and Implementation CDISC Services
Products so you can use CDISC in house!
Product Focus is on Study Specification and Design Tools
Origin™ authoring tools to streamline Protocol to Submission Process
Database Specification uses CDISC Operational Data Model
Origin Study Modeller™
Submission Specification uses CDISC Define.xml
Origin Submission Modeller™
Must work with and around existing processes/technologies
Operational Data Model for EDC auto generation
Existing internal analysis and reporting structures
New or existing extract, transfer and load tools

15. How could CDASH be used today?
Use as a Content Standard
Off the shelf Case Report Form content
Describes relationship between Operational Data and Submission Datasets
CDASH represented within a proprietary file format
Excel, Word, Proprietary EDC system format
Potentially unstructured
Use within Machine Readable Metadata
CDASH represented in CDISC Operational Data Model
Vendor neutral system independent format
Hierarchical structure is ideal for re-usable library of Components

16. Benefits of using CDASH within the CDISC Models
Library Development
CDASH forms represented in CDISC Database Standard
Safety Domains in CDISC Submission Standard
Study Specification
Using CDISC metadata to reduce study set-up time
Automation of Electronic Data Capture Build
Using CDISC ODM to reduce study build times
Optimize Downstream Dataflow
Operational data to submission
Reduces mapping complexity
Makes mappings re-usable

17. What is a CDASH-ODM Form Composed Of?

18. What is CDASH? What is it Not?
Content Standard NOT a Model
Database Variable Name, Definition, Question Text
Instructions to the Site, SDTM Variable Mapping
Core Designations is a killer feature
Give clinical context on why something is collected
Highly Recommended, Recommended/Conditional, Optional
Clinical Perspective on data collection
What is it not?
One to one mapping with the SDTM
AEYN not in SDTM
AEBODSYS not in CDASH

19. ODM Building Blocks How does CDASH Relate?
Clinical Database
Variable Name
Controlled Terminology
CDASH CRF
Label/Question
CDASH Core
(Highly Recommended)

20. CDASH Adverse Event Form in ODM No more hand building of this…

21. A Dedicated Authoring Environment for Each Standard…
Origin Study Modeller™
Origin Submission Modeller™

22. Role Centric Visualizations – Clinician’s eCRF

23. Role Centric Visualizations – Data Manager’s Tabular Specification

24. Multi-Vendor Visualizations – PhaseForward

25. Multi-Vendor Visualizations - Medidata

26. Multi-Vendor Visualizations - Paper

27. Optimal Solution from Standardized Content to any EDC System
I have an alternative to this diagram – this is new. Good because it brings in libraries ……

28. Optimizing Downstream Dataflows CDASH vs. Non CDASH Form Differences1 1 2 2 3 3 4 4 5 5 6 6

29. Optimizing Downstream Dataflows CDASH vs Non CDASH SDTM Differences1 1 5 4 5 4 6 6 2 2 3 3

30. Conclusions CDASH-ODM Delivers Today
Library Development
CDASH brings clinical perspective
CDASH links to SDTM to bring a submission perspective
Quickly settle disputes over content
Streamline Study Set-up and EDC Build Process
Eliminate manual study specification
Study Spec from 492 hrs down to 158 hrs (3x shorter)
30-40% build time reductions
Downstream Raw Data to Submission Dataflow Optimisation
Consistency between Operational Data and Submitted Datasets
Reduction in mapping complexity – quick to create
Mappings easier to maintain

31. CDASH Goals Finalize and Post CDASH final draft for public review
CDASH Roadshow & Training program.
Finalize and Post CDASH V. 1.0 on CDISC.org.
Develop and Publish CDASH-ODM metadata
Establish subgroup, Scope, Deliverables, Participants and Timelines
Identify and Collect feedback from “Early Implementers”
“CDASH” New SDTM Domains as required.

32. Strength through collaboration.
PLEASE VOLUNTEER!!! 32 32