TBPT & CTMS Interoperability

1. TBPT & CTMS Interoperability CTMS Steering Committee Other pertinent info right here November, 2007

2. Outline • CTMS-TBPT Integrative projects • caTissue background • Current caTissue Interoperability • caTissue functionality for shared classes • Cooperative Group Bank Reporting Tool • Lab Information Dynamic Data Exchange (LIDDEx)

3. List of CTMS-TBPT integrative projects • Integration of Trial data into Group Bank Reporting Tool • COPPA/NES and Group Bank Reporting Tool • Integration of clinical path/lab data • LITS Interop* and caExchange/caAdapter • Scheduling activities in the template • Patient Study Calendar/C3PR and caTissue • Linking specimens to the trial design • Patient Study Calendar/C3PR and caTissue • * LITS Interop is now LIDDEx

4. caTissue Core 1.2 – May 2007 • Definition of collection protocols • Profile for collection of specimens on study • Set up different collection events • E.g. maps to multiple specimens collected on a clinical trial • Management of Specimen Inventory • Specimen history • Processing of specimens • Basic annotation • Patient demographics • Specimen location • Simple and Advanced Query • Integration with existing systems - via API • Role based security • caBIG Silver Compatible • caBIG grid compatible – Feb 2008

5. Flexible Specimen Hierarchy Participant Unique Participant Identifier (UPI) Patient Demographic Data Protocol Collection Event Unique Event Identifier (UEI) Event Data Specimen Unique Specimen Identifier (USI) Specimen Data Fluid Specimen Tissue Specimen Cell Specimen Molecular Specimen

6. caTissue Suite 1.0 - April 2008 • Integrated Suite with... • caTIES - Pre processed surgical pathology reports • Clinical Annotation • Enhancements to Core functionality • Specimen Ordering • Consent tracking • Clinical Annotation • Custom Annotation - locally defined • Dynamic Extensions • Saved queries • Frequent queries • For use by non-expert users

7. caTIES Features and Benefits • Extraction of coded information from free text surgical pathology reports • Coded information includes • Diagnosis • Anatomic site • Procedure • Ability to query, browse, and acquire annotated tissue data and physical material across centers UPMC Centers for Pathology & Oncology Informatics

8. caTissue Suite 1.1 – March 2009 • Multirepository functionality • The ability to support multiple repositories within a single installation of caTissue while retaining appropriate security and privacy • Temporal Queries • E.g. querying by patient age • Time between events • E.g. Thaw time • Shipping and Receiving • caGrid compatibility for caTissue Suite • Enhanced clinical annotation capabilities • Lists of values tailored to specific • Ability to create customized forms • Based on standard models • Improved page flow and layout • Performance enhancements

9. caTissue Application Programmers Interface The glue that binds parts together is middleware infrastructure Shape of boundary is defined in APIs • Key part of caBIG compatibility • Writeable “caCORE like” API • Examples of tools developed using the API • Data migration tool • Used for transfer of data from existing database systems • xcaCore • Loads XML files to caTissue • caTissue Loader • Loads tabular data from Excel and text files • Integration with Patient Registration applications • Millions of records have been loaded into caTissue instances via the API

10. caTissue Suite 1.2 • Request for Proposals issued – 4 Sep • Responses to questions posted – 28 Sep • Proposals due – 13 Oct • Award expected – mid Nov

11. caTissue 1.2 priorities • Interoperability with other Life Sciences products • Global identification of specimens over multiple instances of caTissue • Integration with assay systems e.g. caArray • Integration with Clinical Trials Suite • Patient Registry (C3PR) • Patient Study Calendar (PSC) • via SOA • Grid compatibility of Dynamic Extensions • Specimen life history • Integration with Biospecimen Research Database • Implementation of Common Biorepository Model • Maintenance: • Refactoring, re-architecting • Provide a more comprehensive set of Web Services/Grid Services from caTissue. • Address performance of grid services • Support for additional grid query types

12. CTMS storyboards Courtesy of SmitaHastak

13. Post registration storyboard • When a subject is registered to a study, a subject-specific study calendar is created • CRA reviews and validates this information in PSC and activates the study calendar • Biorepository plans activities based on schedule visible in caTissue • Specimen collection/receipt logged by biorepository – visible to CRA • Schedule updates • When a given biospecimen collection activity is scheduled, if the scheduled date is different than the original planned calendar date, the CRA logs into PSC, updates the calendar date with the scheduled date and saves the change. • The new scheduled date is visible to the biorepository staff

14. Pre registration storyboard • Clinical Research Associate (CRA) pre-registers the patient in the registration system (C3PR) • Pre-registration triggers a message to the specimen tracking system (caTissue) to notify it that a specimen is coming • caTissue receives the message and automatically initiates a specimen record with status "expected” • Meanwhile, the specimen is collected and labeled by the Clinical Staff, and sent in a protocol-specific kit to a Central Performing Laboratory which is using caTissue • The Central Performing Laboratory personnel await the arrival of the specimen, process it when it arrives and send the results to the CRA. • Once the subject is determined to be eligible, the CRA registers the subject on the study.

15. Going SOA

16. caTissue Interoperability Status quo Local data storage Collection Protocol Registration Specimen Participant caTissue Web Application caTissue API caTissue caGrid Data Loaders CTMS Registration caB2B

17. Grid Service Oriented Architecture

18. Collection Protocol • The protocol/study for or under which specimens are collected • Broadly equivalent to Clinical Trial Protocol • Biorepositories collect under protocols and studies which are not trials • General collection protocols • Epidemiological studies • Structured Object Model • Collection Events • Time based • Named

19. caTissue version of things • Participant/Person • Protocol et al

20. Protocol details

21. Collection Protocol Event

22. Specimen Requirement

23. Derived Specimen Requirement

24. Consents

25. Participant & Registration • PHI is filtered by role • Instance level security • i.e. PI can see PHI for their participants but not for others

27. Getting to common definitions • Revision of existing services and agreement on new services will • BRIDG and Life Sciences Domain Analysis Model will help • Key area to address

28. Global Unique Identifiers for Biospecimens Stephen Goldstein, Ian Fore, TBPT team and workspace

29. Specimen identification service functions • Obtain a set of identifiers which a system may use until further notice. • Resolve specimen history i.e. given a specimen id find the ids of all its parents • Resolve specimen descendency i.e. given a specimen id find all its children. • Resolve specimen distribution/data availability • i.e. where was a specimen sent to or where has data been stored on it? • It’s really the latter that is important from a caBIG perspective. • Register data on a specimen

30. Relationship to Patient Identification • In some abstractions a patient is a specimen • Okaaaay – but maintain their dignity • Track a patient over time and sites • Always generate the same id for the same patient

31. Next stepsSpecimen ID • Identify other relevant examples of successful use if GUIDs (e.g. ERNE, NIMH, Imaging) • Further vet the baseline assumptions • How uniquely (do we need) to identify a specimen? • (What is the root to anchor that ID and the hierarchy too?) • From a HIPAA point of view can/should you do that? • Follow-up on the NCDB suggestion (hash algorithm) e.g. de-identified and unique

32. CooperativeGroup Bank Reporting Tool

33. Group Banking Committee Reporting Tool Background The NCI-GBC project seeks to harmonize biospecimen data across the NCI sponsored cooperative group banks. Currently, the tissue data generated by the 10 cooperative groups of the Group Banking Committee are collected into a standard GBC data model and repository at Columbus, OH. It is a non-caBIG ongoing effort that collects and shares the summary of the biopsecimen description of the individual specimens, its classification, and some relationship to cases and studies to limited groups. The ten cooperative groups are as follows (multiple banks per group?)

34. GBC - Vision and Scope Vision The main vision here is to create caBIG interoperability of the group banking committee reporting mechanism and to enable sharing of the existing rich collection of GBC data on the caGrid along with new levels of data search and access that are currently unavailable to the Cancer research community. Scope The scope of this NCI-GBC project is to 1) presentthe existing Biospecimen data repository at Columbus, OH on the grid, 2) integrate the COPPA services to provide more details on the clinical trials, and 3) provide a better and improved UI to query, search and retrieve the biospecimen data securely from the grid from the publically available caTissue instances as well as the gridified central data repository.

35. Integration of Trial data into Group Bank Reporting Tool • Display relevant trial information • Search for specimens on trial characteristics • E.g. Specimens from colon cancer trials • Trial data remains in COPPA • Service oriented architecture

39. GBC – Key Functional Objectives Features • Gridify the Reporting Tool - To provide a Data Service to securely share/view and search data • Build a UML Model based on the existing information model • Generate a Data Service from the UML Model and publish it to the Grid • Provide secured access to the shared data • Create grid-based client application to retrieve/grab the data from caTissue Grid service and update the local database. • Choose at least two caTissue adopters from the Group Banking Committee to share their data on the grid • Build a web-based application to interface with the data grid service to display all the identified Clinical Trial IDs (Protocol IDs), which in turn will invoke COPPA service to display all the ClinicalTrialID information.

40. GBC – Collaboration with Clinical Sciences Collaboration: Integrating the COPPA/CTRP services to access the comprehensive database containing regularly updated information on all NCI-funded interventional clinical trials and display the report about the cancer clinical trial data. This harmonization with the Clinical Science application will lead the bio bankers/researchers to the important and useful information about the clinical trials to coordinate and facilitate research efforts , which otherwise would not be possible with one single click.

41. Laboratory Information Dynamic Data Exchange(LIDDEx)

42. LIDDEx background • A service oriented architecture for Clinical Pathology • Originally LITS Interop • Lab InfoTech Summit • Major Clinical Pathology Informatics meeting • University of Michigan • Bruce Friedman & Ulysses Balis • LITS 2008 – Concept issued, challenge issued • LITS 2009 – Initial version • Simple service • Exchanged text blob • APIII 2009 – Semantic • XML Schema based on LOINC codes • APIII 2010 – Secure production services

43. LIDDEx participants • University of Michigan – Leadership - Ulysses Balis • Emory University • Clinical Pathology Lab Information System Vendors • Atlas Development Corp • McKesson • mTuitive • SCC Soft Computer • Sunquest Information Systems • TechniData • Rules based engine • Pacific Knowledge Systems

44. Mutual benefit • What doescaGrid have to offer LIDDEx • Stateful services • Discovery • Security infrastructure • Trust Fabric • Semantic integration • What does LIDDEx have to offer caBIG • Commitment to and experience with services • Participation of key CP LIS vendors • Services and cloud implemented

45. Concerns • Overabstraction • Correlation • Too generic • We need the specific associations the users understand