Data Analysis Interface for Cancer Centers and Stand Alone Submission Infrastructure

1. Data Analysis Interface for Cancer Centers and Stand Alone Submission Infrastructure Monday, January 30, 2006

2. Project Scope • Establish a centralized and independent infrastructure for data submission associated with clinical trials for all of NCI • Electronic submission • WEB based submission • Transition CTEP to start using new NCICB established infrastructure • Develop a mechanism to provide data access (analysis and reporting) to stakeholders including cancer centers, cooperative groups and single institutions

3. Project Tasks • Task I (CDS – SL) • Stand Alone Submission Infrastructure – Reuse CDUS Smart Loader (SL) • Task II (CDS – Web) • WEB based data entry (submission) mechanisms for single institutions (including transition for CTEP) – Reuse CDUS-Web • Task III (CDS – AR) • Data Analysis and Reporting Interface for Cancer Centers – Reuse CDUS Reports • Task IV • Routing CDUS SL data entry point from CTEP to NCICB (includes data migration & performance tuning) – single submission mechanism • Task V • Mapping CDUS/CTMS data elements to Janus/SDTM –Gap Analysis • Task VI • Analyze technology infrastructure using SDTM data standards (Out of Scope) – Standardization • Task VII • Assess Feasibility of getting CTMS data sets using current technology (CDS- SL) • Task VIII • Conduct Gap Analysis for supporting Summary 3 and 4 reports against current infrastructure

4. Implementation Schedule • Task I (CDS – SL) – ~ June 2006 • Task II (CDS – Web) – ~ March 2006 • Task III (CDS – AR) – ~ April 2006 • Task IV – ~ June 2006 • Task V – ~ February 2006 • Task VI – TBD • Task VII – March 2006 • Task VIII – March 2006

5. Task I – Submission Infrastructure (CDS – Smart Loader) • Develop an independent and stand alone data submission infrastructure (electronic) at NCICB to serve as the primarydataresourcefor NCI sponsored clinical trials • Submit data via secure FTP server • Assess feasibility of data submission via secure web services (CDUS-CTMS SIG recommendation)

6. Task I – CDS – SL Technology • Reuse technology adapted by CTEP (CDUS-SL) • Transfer the as is model from CTEP As is technology to be used • Oracle database • Oracle Reports • Oracle PL/SQL Technology used to be caBIG compliant • Java based interface to build supporting application – Protocol Abstraction, Dose Regimen, Entity Definition and Relationships

7. Task I – CDS – SL What data is submitted • CDUS Abbreviated • Protocol Administrative (i.e. status) • Patient Demographics (i.e. race, ethnicity, gender, etc.) • CDUS Complete • Protocol Administrative • Patient Demographics & Administrative (i.e. patient on trial) • Response, Toxicity, End Points, Publications & Authors, General Data Summary • All submitted data should be CUMULATIVE

8. Task I – CDS – SL Smart Loader Approval, Disapproval, and Correction Process • Data loads are either successful or unsuccessful (partial success is not an option) • Data Elements have been grouped into the following three categories: • Mandatory • Requested • Optional

9. Task I – CDS – SL Smart Loader Approval, Disapproval, and Correction Process Cont(…) • Mandatory data elements • These are defined by CTEP as the minimum information required for processing the data submission and to track patient enrollment on study • Investigators must submit all mandatory data elements • Requested Data elements • These are defined by CTEP as the minimal information necessary to fulfill the regulatory, scientific and administrative needs of the NCI • Investigators must provide all known requested data elements • Optional Data Elements • In general the optional fields are free text. These fields should be used by investigators to provide additional data that may not be readily apparent from other information submitted • Submission of optional data is at the investigators discretion

10. Task I – CDS – SL Smart Loader Approval, Disapproval, and Correction Process Cont(…) • The Anticipated problems with the submitted data have been grouped into 4 categories • Incomplete – Data files that do not contain all mandatory and requested data elements will be considered incomplete • Incorrect – Data that are submitted in the wrong format or with invalid values • In appropriate – Data that do not meet electronically preset criteria (e.g. patient weight > 120 kg or first date of treatment > protocol activation date) • Inconsistent – Data elements that are not expected to change from one submission to the next (e.g. patients gender)

11. Data Type Problem Type Incomplete Incorrect Inappropriate Inconsistent Mandatory Data • - All data rejected • - List of missing data • elements generated with • Rejection Notice • - Resubmission required • within 5 working days - All data rejected - List of errors generated with Rejection Notice - Resubmission required within 5 working days - All data rejected - List of errors generated with Rejection Notice - Resubmission required within 5 working days - All data accepted - List of errors generated with Caution Notice - Verification or submission of corrected data due for next quarter’s submission Requested Data - Remaining data set is accepted - List of missing data elements generated with Caution Notice - Verification or submission of corrected data due for next quarter’s submission • - All data rejected • List of errors generated • with Rejection Notice • Resubmission required • within 5 working days • - All data accepted • List of errors generated • with Caution Notice • Verification or • submission of corrected • data due for next • quarter’s submission • - All data accepted • List of errors generated • with Caution Notice • Verification or • submission of corrected • data due for next • quarter’s submission Optional Data N/A N/A N/A • - All data accepted· • List of errors generated • with Caution Notice· • Verification or • submission of corrected • data due for next • quarter’s submission Task I – CDS – SL Smart Loader Approval, Disapproval, and Correction Process Cont(…)

12. Task I – CDS – SL Requirements • Develop Java based interfaces (leverage caFRAMEWORK) for the following base modules to allow SmartLoader to function independently: • Protocol Abstraction Module – for protocol related attributes and administrative information such as Lead Organizations, etc. • Dose Regimen Module – for treatment assignment related information • Entity Definition and Relationship Module – for setting up appropriate security privileges and other profile information • Create stand-alone Oracle instance of appropriate table structures and reference data including reference data such as gender/race codes etc., and MedDRA, CTCAE vocabularies at NCICB • Setup independent FTP site for data submission to this new infrastructure (assess feasibility of web services based submission mechanism) • Develop appropriate use cases and appropriate system/technical documentation • Map all CDUS data elements to CDEs in caDSR

13. “Collection”,”T99-0019”,… “Patients”,”T99-0019”,… Task I – (CDS – SL) Process Load Status/Error Log Meta Data Cancer Centers/Sites Submission Database Extract Data FTP Server SL Security Layer Supporting Applications Data Files (Comma delimited) Reference Data Entity Relationship Dose Regimen Protocol Abstraction Sponsor

14. Task I – (CDS – SL) Data Loading Process

15. Task II – Web Entry/Submission (CDS – Web) • Develop an independent and stand alone submission infrastructure at NCICB (web entry) to serve as the primary data resource for NCI sponsored clinical trials • Enter/Submit data via a web based interface

16. Task II – Web Entry/Submission (CDS – Web) Requirements • Implement a web based infrastructure to submit clinical data • Develop appropriate use cases and appropriate system/technical documentation

17. SL Security Layer Convert to Data Files (Comma delimited) Web Submission “Collection”,”T99-0019”,… “Patients”,”T99-0019”,… Sponsor Task II – Web Entry/Submission (CDS – Web) Process Load Status/Error Log Cancer Center Meta Data Submit Data CTEP Analysis and Submission Database Submission Database Data Bridge Supporting Applications Reference Data Entity Relationship Dose Regimen Protocol Abstraction

18. Task II – Web Entry/Submission (CDS – Web) Technical Architecture

19. Task III – Data Analysis Interface (CDS – AR) • Data Analysis Interface for Cancer Centers to retrieve the clinical data submitted via CDUS • The data analysis interface enables the users to view and generate reports about various aspects of the clinical trial process. • The scope of this task is limited to existing data reports that are available internally to CTEP staff

20. Task III – Data Analysis Interface (CDS – AR) Technology • Reuse technology adapted by CTEP • Transfer the as is model from CTEP As is technology to be used • Oracle database • Oracle Reports Technology used to be caBIG compliant • Java based interface to query data

21. Task III – Data Analysis Interface (CDS – AR) Requirements • Redesign and develop new Java based interface/query screens for providing access to CDU-Reports • Build additional security layer as appropriate for authorization and authentication and limiting access based on protocols and/or institution • Develop appropriate use cases and appropriate system and user documentation • The data and infrastructure for this effort will be hosted at NCICB • Develop necessary interfaces to ESYS for refreshing data into the NCICB repository (interim need)

22. Task III – Data Analysis Interface (CDS – AR) List of Reports • Accrual Reports • Accrual by protocol • Accrual by Gender/Race • Accrual by Institution • Estimated Vs. Actual accrual • Document milestones • Adverse Event Reports • Adverse Event • Patient specific AE • Subgroup Adverse Event • Subgroup Response and Adverse Event • Correlative Study Findings Report • Demographic Reports • Patient Demographic • Population Demographic • Patient Dropout Report • Publication Report • Response Reports • Response Information • Response and Adverse Event • Subgroup Response and Adverse Event

23. Task III – Data Analysis Interface (CDS – AR) Process Query Builder Query Data Cancer Center Java Interface Analysis Database Submission Database Security Layer Sponsor Supporting Applications Reference Data Entity Relationship Dose Regimen Protocol Abstraction

24. Task III – Data Analysis Interface Technical Architecture

25. Task IV • Routing CDUS data entry point from CTEP to NCICB • Provides the sites with a centralized parser to verify the data prior to submission • Perform 3-6 months of setup/testing in parallel with CDUS SL at CTEP • Develop and test routines to update data to and from CTEP-ESYS • Setup/testing involved for migrating FTP sites and file server for storing submitted data • Training and communication for sites, CDUS operations team • Identify, test and resolve issues associated with use of infrastructure to support multiple sponsors • Synchronize changes/bug fixes and enhancements done locally by CTEP • Performance tuning • Harmonization between sponsors on new business rules • Maintenance of software on updating new business rules

26. Query Data Query Data Query Builder Java Interface Cancer Center Meta Data Submit Data CTEP Security Layer Security Layer Enterprise Database Submission Database Analysis Database SL FTP Server Extract Data Web Submission Supporting Applications Reference Data Entity Relationship Dose Regimen Protocol Abstraction Sponsor “Collection”,”T99-0019”,… “Patients”,”T99-0019”,… Convert to Data Files (Comma delimited) Query Data Task IV Process

27. Task V • Mapping CDUS and CTMS data elements to Janus/SDTM

28. Task VI (Out of Scope) • Analyze technology infrastructure using SDTM data standards • Design and Development of standards based SDTM submission infrastructure

29. Out of Scope • Task VI • Accepting data using web services – will explore feasibility • Access to data via APIs • Error logs in computable format

30. Limitations • One CDUS operations team • Cannot have sponsor specific business rules • 2 types of submission – Abbreviated and Complete (No customization) • Performance • Plug and play dictionaries not allowed • Customized LOV for individual site/protocol not possible

31. Risks • Potential security issues • Current CDUS infrastructure has limitations that will soon need to overcome – requiring a redesign based on SDTM (Task VI) • Ongoing change management and maintenance plan will need to be defined as multiple sponsors start using the infrastructure

32. Questions