Rhoda Z. Arzoomanian University of Wisconsin Face-To-Face COH, Duarte, CA November 16-17, 2004

1. CTMS/CDUS SIG Rhoda Z. Arzoomanian University of Wisconsin Face-To-Face COH, Duarte, CA November 16-17, 2004

2. AGENDA: • Strategies to Develop White Papers (4) • Questions to be developed in White Papers • Additional Questions to be Developed by this SIG • Future Direction……???…….

3. GOALS: • Short Term: (within 3-6 months) • Identify issues with current reporting system • Have identified 4 so far • Develop white papers around these issues • Long Term: (prototype for testing within 3-5 years) • Is reporting the right use case? • If all organizations are on the Grid, can NCI, others simply query the Grid for information? • No reporting mechanisms would be needed • Allow access to “published” data on the Grid • caSPR would serve as integrating mechanism • Simplify the workflow and reporting!

4. STRATEGIES TO DEVELOP INTO WHITE PAPERS: To date: Identified four questions to develop into White Papers Goals of White Papers: • Serve as a prelude to the developers for a SOW as it will describe the nature of the project • Mechanism to move the Workspace to a consensus position for a controlling audience and thus create a workspace to harmonize requirements to improve and simplify reporting

5. QUESTIONS TO BE DEVELOPED INTO WHITE PAPERS • Harmonization of CTMS and CDUS Data Fields • Reports Required from Data Transmission/Submission • Data Transmission/Submission Acknowledgements • Definition of Security for Submission Standards

6. CTMS/CDUS SIG – White Paper #1 Harmonization of CTMS and CDUS data fields Sharon Elcombe Mayo Clinic Duarte, California November 16-17, 2004

7. Background • CTMS, CDUS, and AdEERS reporting systems each have their own requirements for data definitions • If they are not harmonized, separate requirements for CTMS, CDUS, and AdEERS will be needed as they interface with any systems developed in the future • Lack of harmonization currently creates problems! • For the white paper, we need examples from each cancer center

8. Recommendations • NCI continues the process of making CDUS reporting requirements CDE compliant – this is great! • Explore CDE compliance as it relates to CTMS and AdEERS reporting • Who can do this? NCI? Others??

9. Reports Required from Data Transmission/Submissions (White Paper #2) Rhoda Z. Arzoomanian University of Wisconsin Face-To-Face COH, Duarte, CA November 16-17, 2004

10. Desired Reports • Reports that monitor the ongoing CDUS/CTMS submission process and document different stages of the submission, and allow ‘publishers’ to review their data at any stage • This enhances our ability for comparative results of studies • Studies with same agents • Studies with same agent, different phases • Studies with same disease and different agent • Others????

11. Suggestions?

12. Data Transmission/Submission Acknowledgements (White Paper #3) Brenda Crocker/John Milnes PITT/UPMC Face-To-Face COH, Duarte, CA November 16-17, 2004

13. Transmission Requirements • What protocol to recommend, can we? ftp, sftp, sctp, https, web services,… A. CommonProtocol Requirements: • EstablishConnection:This process may involve circuit switching to make a physical connection. Need to pass the username/password securely. • Initialization:The process will check that the connection is correctly made. • Transfer:It is at this stage where the correct transfer of characters or blocks of data takes place. • Acknowledgement:Both computers involved in the transfer of data agree that the transfer is complete. • Release:The connection (physical or otherwise) is broken

14. Acknowledgement Types • Areas of Acknowledgement fall into two basic types A. Transfer Validation • Did the recipient get the complete contents of the transfer accurately • Audit information on transfer source, date, time, file size. B. Data Validation • Is the content of the transmission accurate (record counts) • Is data parsed without error

15. Transfer Validation Requirements • Transfer Validation A. Common techniques for transfer validation include: • Application level cyclic-redundancy checks • MD5 (Verification algorithm for secure compressed transmissions) • SFV (Simple File Verification) • Transfer Validation Report A. The report should include the following for each transmission: • Username • Filename • Location • Mode (binary, ascii) • Date/time • Before and after byte counts

16. Data Validation Requirements • Data Validation A. What to validate? • Parsed with counts of each record type returned • Return list of errors or no errors • Data Confirmation Reports A. Current CDUS • Error Log Report Shows any records that were not successfully received by requesting agency • Successful Log Report A listing by table name showing counts of accepted records • Caution Log Report List any requested or optional data that is inappropriate or inconsistent • Summary Log Report Shows information on any rejected protocols • Code Reference/Error Description Report Documents all possible error codes for rejection of records

17. Recommendations • File Transport Protocol must be Open Source • Establishment of an accessible ‘validator’ that is blessed by the NCI • Encryption and Security – White Paper #4 • Single Data Validation Report • Report should be returned in a timely manner • For fully successful transmissions, summary report section only

18. Suggestions?

19. #4 Definition of Security for Submission Standards Sorena Nadaf, Vanderbilt Warren Kibbe, Northwestern

20. Building Blocks for secure submissions • Web services • SSL for encryption • Authentication using Kerberos/SAML • Authorization, identity management using LDAP • All are part of Shibboleth http://shibboleth.internet2.edu/

21. DemoCTMS Chicago Vanderbilt Interoperability Sorena Nadaf, Vanderbilt Warren Kibbe, Northwestern

22. Inter-institutional Interoperability • Background • Building Blocks • CDEs • Web services • SSL for encryption • Authentication using Kerberos/SAML • Authorization, identity management using LDAP • All of these pieces are used in Shibboleth http://shibboleth.internet2.edu/ • Demo

23. Background Interoperability • Ability to publish and subscribeto data definition standards (CDEs!) • Ability to authenticate users • Ability to authorize users • Ability to federate identity management

24. Background Data sharing • Ability of two organizations to send data at an arbitrary (but mutually agreed upon!) level of granularity • Ability to share clinical research data is augmented by de-identification of PHI • Requires security, legal, and technical agreements

25. Background Advantages of “transparent” data sharing • Speed of transfer • Acknowledgement of receipt • Compliance • Statistical power (larger populations can be studied)

26. Background Example Sharing adverse event information This is only one of many examples of areas where sharing of data will have an immediate benefit for cancer patients Targeted groups Cancer center to cancer center Cancer center to cooperative group Cooperative group to cancer center Cancer center to NCI Cancer center to FDA

27. Building Blocks • CDEs • Web services • SSL for encryption • Authentication using Kerberos/SAML • Authorization, identity management using LDAP • All but CDEs are part of Shibboleth http://shibboleth.internet2.edu/

28. What we built • Simple AE schema in Oracle • Data dictionary in Oracle (we would like to use the CDEs for this!) • Used the published CTC for AE definitions • Used the existing NU AE entry module • Web services servlet • Web services browser • WSDL file

29. Schema(ERD)

30. Data Dictionary

31. Common Toxicity Criteria Browser

32. Adverse Event Entry Form

33. Adverse Event Tablespace

34. Webservice Component

35. Webservice Component 2

36. Webservice WSDL file

37. Webservice ‘consumer’ view

38. Data from the Webservice

39. Additional Questions to be Developed by this SIG ???????

40. Future Direction: Harmonization is Essential – Mandatory – Non-Negotiable