1. What are those 3 Cs??

2. C3D Status (as of 2/24/05 12:12 pm)  5 Centers – NCI Center for Cancer Research – National Naval Medical Center – University of California at Irvine Chao Family Cancer Center – Georgetown University Lombardi Cancer Center – University of Colorado - Lung SPORE  15 Participating sites  35 PIs  59 Studies  1767 Patients  116,271 Completed eCRFs  621,458 Lab Results automatically loaded  6,086,536 Non null responses  15,869,105 Total responses

3. On the horizon  Translational projects – Director’s Challenge – REMBRANDT  caBIG Adopters – University of Pennsylvania – Albert Einstein at Yeshiva University – Oregon Health Science University – Duke University  SPOREs – MD Anderson - Head and Neck  Cancer Imaging Program

4. Problems C3D is solving  Decrease individual protocol set up time  Increase use of standards – data elements and CRFs  Provide remote data capture across study sites  Provide data collection in compliance with regulations (21CFR11)  Ease regulatory submission burden – CTMS – CDUS  Decrease local support costs – ASP model  Decrease Oracle Clinical cost of ownership – both ASP and local models

5. C3D Limitations  Built around proprietary technology – Oracle, 9iAS, Forms, PL/SQL – NCICB is pushing Oracle to provide complete metadata APIs – Oracle has committed to accept/process standard CRF message  Currently not supported on Apple Mac OS – No JInitiator for Mac  All data stored as character – limited to 200 characters – No database level support for data types – Date and Numeric type checking at data entry – can be overridden by “verbatim” data  Not HL7 compatible – HTB/OC Integration is in sight – Oracle re-organization (previous OC development VP replaced by HTB VP)

6. C3PR Status  Release 1 scheduled for mid March 2005 – This release will not be used by CCR – This release will be available to caBIG adopters – This release does not handle randomization  Release 2 scheduled for summer 2005 – This release will be used by CCR – This release will support assignment of externally determined randomization

7. Problems C3PR is expected to solve  Provide central registry for all protocols  Provide access to clinical data by name (and other identifying information)  Provide links between different kinds of data about the same person (or study subject)  Support HIPAA compliance by keeping all the identifying data in one system

8. Special Considerations  FDA regulation – 21 CFR Part 11  System validation – in progress  Standard Operating Procedures – C3DS Users Group vetting  High availability – not designed for patient care, but must meet reporting deadlines  HIPAA data – isolate identifying data in C3PR

9. Library of Template CRFs Built with CDEs  Forms and CDEs defined in caDSR  Template CRF layouts defined as PDF

10. CDE/Value Domain Details  Common Definitions  Common Representations  Common Values  Semantically Interoperable

11. C3PR/C3DS Single Sign On Home Page Mockup

12. C3PR Participant Registration History Search by Name – Access to clinical data in C3D

13. C3PR Add Registration  Patient Details – Demography – Primary address  Protocol Details  Eligibility Checklist – Imported from caDSR – Status computed

14. Eligibility Checklist implemented in caDSR FormBuilder

15. Oracle Clinical 4.5 RDC CRF Matrix Header identifies Database, User, Site & Study Tabs identify Visits/Phases Planned CRF pages for each visit define column headers Unplanned pages can be added Left column identifies Patients by position number and initials Matrix cells indicated state of CRF page for each patient Colors indicate discrepancy status Red - this user’s problem Yellow - other user’s problem Checks indicate Verification and Approval status Lower section of screen provides access to Summary, Discrepancy details &Audit Trail

16. RDC 4.5 Graphic Layout (PDF)  It looks like paper  Less training  PDF globally accepted/endorsed as submission vehicle  Combs/Images/Logos  Adobe plug-in  RDC Toolbar  PDF is background – Only requires Reader  Data stored the same way

17. Single click on Cell opens blank PDF form

18. Hand/Select tool active

19. Single select checkboxes Multi select checkboxes Auto date format

20. Picklist indicator

21. After Save and Close, Red color indicates Discrepancy

22. Red color indicates Discrepant Field(s) Discrepancy Management tool active

23. Generated Discrepancy message is configurable Discrepancy Reason based on edit checks

24. Adding missing Mandatory Consent Date triggers audit trail With configurable list of Reasons. User and timestamp are automatic.

25. After Save, Red becomes white. Activating Audit History Tool identifies audited fields with color Blue.

26. Audit History tool active Clicking on Audited field Opens Audit History

27. After Save, Red becomes white. This data is clean.

28. What’s Next?  Definition of HL7 v3 CRF message – Extension of caDSR to support CRF and message – Build entire CRFs in caDSR and publish to C3D via HL7 message  Integration/Interface with HTB HL7 repository – Semantic interoperability brings the promise of self populating CRFs via HL7 v3 message mapping  C3VS – interface with EVS to provide C3D with JIT vocabulary  C3PR adoption  More C3D ASP adoption  First locally hosted C3D adoption  Implement caBIO like Clinical Object Model interface on top of C3D

29. Questions?