1. DRAFT of Proposed TRANSCEND Integration Architecture March 2011

2. Table of Contents Overview –iSPY2 Trial –TRANSCEND Architectural Goals & Challenges Proposed Technical Architecture –Overview –2TRANSCEND Requirements –Individual Architectural Components Adverse Events (AE) Subject Registration Array data iHub (formerly caXchange) 2

3. Overview I-SPY2 Trial –Investigation of Serial Studies to Predict Your Therapeutic Response with Imaging And moLecular Analysis 2 –Process for rapid, focused clinical development of paired oncologic therapies and biomarkers –Phase 2 adaptive design clinical trial program for the neoadjuvant setting in women with newly diagnosed breast cancer To determine whether adding investigational drugs to standard chemotherapy is beneficial To allow rapid assessment of targeted therapeutics with proximal endpoints of response TRANSCEND –Translational Informatics System to Coordinate Emerging Biomarkers, Novel Agents and Clinical Data –Support adaptive clinical trials such as I-SPY 2 –Currently deployed in phase I supporting limited integration –Phase II to expand integration with various other tools and services 3

4. TRANSCEND Integration Architecture - Goals Automated integration of trial participant information into local institutional CTMS Automated integration of TRANSCEND with Laboratory Information Systems for laboratory data coming from each study site’s local clinic Ability to rapidly compare experimental results from multiple labs with the quality data currently being tracked in caTissue Suite Automated integration of trial data with an adverse event reporting system through an enhanced data interface Adopt and integrate additional imaging tools that annotate and track lesions identified by MRI and other imaging platforms Enable single sign on amongst various applications 4

5. TRANSCEND Integration Architecture - Challenges Provide a Service Oriented Architecture that allows integration with different caBIG developed tools and services as well as third party tools and services Interoperate between services and tools that support: –Different Platforms –Different Protocols –Different Message Structures / Formats –Different Authentication Mechanisms Provide a secured environment to transmit and store Patient Identifiable Information Provide mechanism to allow integration of tools and services deployed at study sites with the central coordinating center 5

6. Subject Registrations (Grid) Adverse Events (Grid) Subject Registrations Subject Registrations Biospecimens Lab Results (Grid) IN: Lab Results OUT: Subject Registrations Clinical Notes Adverse Events Biospecimens Lab Results Arrays Images (Grid) Register Subjects Track Subject Activities Report Adverse Events Reports Analyze Trial Data Collect & Track Biospecimens Registration Service [1B] AE Grid Service [2A] Enterprise Service Bus caTissue API [1D, 3C] Semantic Infrastructure caArray Service [TBD] caAERS [3A] caArray [1D?] caIntegrator [1D, 2E, 3B, 3E] Tolven (CDMS) Web Applications Infrastructure Services & API CCHC [1C] RIM/CDA Service [1A] Clinical Notes (CDA) caTissue [1D, 3C] Conduct Array Experiments EMRs Patient Clinical Care caBIG Services caBIG Web Applications Trial Sites iSPY2 Trial Users caAERS Single Sign On NBIA [2D] PRO CTCAE [2C] ACRIN NBIA Grid Service [2D] Images (Grid) Patients Report Outcomes Terminologies Common Data Elements Finalize AE Report Serious AE Input Image Information EMRs Registration Consumer Grid [1B] caIntegrator Registration Service [1B] Subject Registrations Trial Sites

7. White Paper Section Requirement 1A Integration of TRANSCEND with electronic health record systems (EHRs) systems using an HL-7 based messaging. At a minimum, allow TRANSCEND (Tolven) to "push" a clinical note record to the local EHR for inclusion in the patient's institutional record. 1B Automated integration of trial participant information into local institutional Clinical Trial Management Systems (CTMS) and regulatory systems. 1C Automated integration of TRANSCEND with Laboratory Information Systems (LISs) for laboratory data coming from each study site’s local clinic. 1D Integration between TRANSCEND and local bio-repositories for managing the processing and reporting of experimental assays using study bio-specimens. 2A Automated integration of trial data with an adverse event reporting system through an enhanced data exchange interface. 2B Web-based patient communication and care plan that integrate the trial schedule, including treatment and procedures, into a personal calendar.. (Not represented on architecture chart.) 2C Web interface for trial patients to report side effects they are experiencing while on treatment. 2D Adopt and integrate additional imaging tools that annotate and track lesions identified by MRI and other imaging platforms. 2E Improve automated trial administrative capabilities within TRANSCEND that include analytic tools.

8. White Paper Section Requirement 3A Developing analytical functionality within an Adverse Event Report System 3B Improve trial data portal (i.e. caIntegrator) to enable specifying a user’s access to limited trial data. 3C Improve electronic bio-specimen repository system to allow for user expansion of additional types of bio-specimens collected and develop better analytical and quality management functions. 3D Enhance TRANSCEND functionality so current HL7 coded trial data can map to CDIS semantics. (Not represented on architecture chart.) 3E Enhance trial data portal to increase the traceability and reproducibility of statistical analysis that is done with trial data. 3F Enhance ability to capture structured clinical data through "XML EDC Forms“. (Not represented on architecture chart.) NOTE: a.The proposed architecture utilizes an Enterprise Service Bus (ESB) as the integration platform. This can be either ServiceMix, MirthConnect or any other ESB b.This platform will require additional caBIG specific capabilities (provided by iHub) to interact with caBIG/caGrid Services

9. Integration Scenarios 1. Adverse Events (AE) 9

10. Integration Scenarios – Adverse Events (AE) Leverages existing caAERS instance deployed as part of TRANSCEND for I-SPY2 Leverages existing business process of users entering the Adverse Events into Tolven Adverse Events will be provided by Tolven in its TRIM format Uses newly developed Adverse Events Grid Service Interface to push Adverse Events into caAERS 10

11. Adverse Events (AE) Integration Workflow 1.User logs in to Tolven using Single Sign On to register an adverse event for the patient on the I-SPY2 trial 2.Tolven is enhanced to transmit the adverse event message to ESB(iHub) in TRIM format. 3.ESB(iHub) converts the Adverse Event from TRIM format to the BRIDG based format accepted by caAERS AE Service 4.ESB(iHub) obtains Grid credentials from NCI’s Production using the configured common username and password 5.ESB(iHub) invokes the caAERS AE service to transfer AE data, using the obtained Grid Credentials 6.User logs into caAERS to complete serious adverse event reporting 11 Tolven ESB (iHub) caAERS 2. Adverse Events (TRIM) SSO Grid Service 5. Adverse Events 6. Report Serious Adverse Events 3. Convert from TRIM to caAERS Format 4. Obtain Grid Credential NCI’s Production Grid

12. Integration Scenarios 2. Subject Registrations 12

13. Integration Scenarios – Subject Registration Leverages existing TRIM based patient registration messaging capability of Tolven (which is already used for caTissue integration) Leverages existing caBIG Clinical Trials Suite’s Subject Registration message for transmission of registrations to caAERS Requires the Site’s EMR to stand up new Registration Services to consume and store subject registrations Does not require deployment of C3PR web application or the related Subject Registration enterprise service Contd. on next slide 13

14. Integration Scenarios – Subject Registration (contd.) caAERS already provides the Registration Consumer Grid Interface; so can start receiving registrations out of the box Requires caIntegrator to stand up a new Registration Service Interface to accept clinical data / annotation from Tolven ESB(iHub) is already configured to understand and route the Subject Registration message Existing TRIM based patient registration message from Tolven needs to be enhanced to provide the minimal set of attributes required by the existing Registration Consumer Interface Requires using caGrid 1.x security framework and tools for integration with caAERS Registration Consumer Service 14

15. Subject Registration Integration Workflow 1.User logs in to Tolven using caGrid’s WebSSO (Single Sign On) to register a patient (subject) to the I-SPY2 trial 2.Tolven transmits the patient registration to ESB(iHub) in TRIM format. This message is enhanced to include all the fields that are needed by Registration Consumer Interface (at minimum) 3.ESB(iHub) identifies the message as a subject registration message and: a.Converts it into caTissue Object using the existing caTissue API based Transformation b.Converts into Suite’s Subject Registration message for transmission to caAERS c.Converts the message into new Subject Registration message for transmission to the sites as well as caIntegrator (Detailed message TBD) 4.ESB(iHub) Transmit the message to caTissue API using the existing integration 5.ESB(iHub) transmits the suite’s subject registration message to caAERS Grid Service Interface 6.caIntegrator will stand up a new Registration Service to receive the New Subject Registration message from ESB(iHub) 7.ESB(iHub) transmits the new subject registration message to Registration Service hosted by individual Site’s EMRs 15 Tolven 1. Authenticate User ESB(iHub) caIntegrator caAERS (GRID) caTissue 2. Subject Registration (TRIM) SSO API Registration Consumer Registration Service 3. Convert from TRIM in to various formats EMRs (Sites) 4. caTissue Objects 5. Suite’s Subject Registration (GRID) 6. New Subject Registration Message Registration Service 7. New Subject Registration Message

16. Integration Scenarios 3. Lab Results 16

17. Integration Scenarios – Lab Results Leverages the existing Cancer Center Hub Client (CCHC) which: –Accepts a lab message from LIMS or EHR system in to a CSV or HL7v2 based flat files –Provides caAdapter’s based transformation capability to convert these CSV or HL7v2 based messages into HL7v3 RIM based message –Transmits the message to ESB(iHub) using the Grid Interface Site’s EMR will be publish the lab results in form of CSV or HL7v2 based flat files for CCHC to consume ESB(iHub) will be configured to convert HL7v3 RIM based Lab Messages into TRIM message format acceptable by Tolven ESB(iHub) will be configured to route this TRIM message to Tolven 17

18. Lab Data Integration Workflow 1.User exports the lab results from the Site’s EMR into CSV or HL7v2 flat files 2.CCHC picks up these files and transforms them into HL7v3 based messages 3.Obtain Grid Credential using the configured user identity (username/password) 4.CCHC transmits these HL7v3 messages to ESB(iHub) using Grid Interface for further routing 5.ESB(iHub) transforms the incoming HL7v3 message into TRIM format acceptable by Tolven 6.ESB(iHub) transmit the TRIM message to Tolven via the TRIM interface 18 EMRs (Sites) 1. Export Lab Results ESB(iHub) Tolven 2. Transform from CSV / HLv2 toHL7v3 TRIM Interface 5. Transform HL7v3 to TRIM 6. Transmit TRIM Message 4. Transmit HL7v3 Message (Grid) CCHC (Sites) CSV HL7v2 3. Obtain Grid Credential NCI’s Production Grid

19. Integration Scenarios 4. Array Data 19

20. Integration Scenarios – Arrays Leverages already installed caArray instance for TRANSCEND Leverages the existing caArray EJB Service Interface to transfer data to caIntegrator caIntegrator can be enhanced to –Use caGrid’s WebSSO to provide single sign on capabilities –Provide Role based authorization for sample-level security CSM (Common Security Module) could be used to provide this capability 20

21. Arrays Integration Workflow 1.User logs in to caArray(which can also be secured using SSO) and captures results for the array experiments. 2.User logs in to caIntegrator using SSO 3.User registers the caArray instance as a source of Array data 4.Notification about new data being available in caArray is required by caIntegrator (this can be either pushed or pulled from caArray) 5.User fetches the array information from caArray into caIntegrator (this fetch will use caArray’s EJB Service Interface underneath) 21 caArray 1. & 2. Authenticate User 5. Array Data SSO caIntegrator 3. Configure caArray Instance EJB Service 4. New Array Data Notification

22. Integration Scenarios 5. caGrid Usage 22

23. caGrid Usage in TRANSCEND Integration Scenarios Subject Registration Integration Scenario –caAERS already provides a Registration Consumer Grid Interface –Transmitting Registrations to caAERS will require use of Grid Security and Message Infrastructure Adverse Events Integration Scenario –caAERS Adverse Event Enterprise Service provides a Grid Interface –Transmitting Adverse Events to caAERS will require use of Grid Security and Message Infrastructure Imaging Integration Scenario –NBIA’s Imaging Service provides a Grid Interface –Retrieval of imaging data into caIntegrator will require use of Grid Security and messaging infrastructure Lab Results Integration Scenario –CCHC currently transmit HL7v3 message to iHub’s existing Grid Interface caGrid’s WebSSO can be leveraged as a SSO framework –Requires usage caGrid’s Security Framework for authenticating the users –Can use the caGrid Security Services deployed on NCI’s Production Grid Might require all users to be provision on NCI’s Production Grid* 23

24. caGrid Impacts on TRANSCEND Deploy existing Grid Services for caAERS and NBIA –Similar to deploying any other Web or RESTful Service (except for an additional caGrid component to sync with NCI’s Trust Fabric) Create/Update common users on NCI’s Production Grid. These user identities are used to connect to Grid Services –To be done once every year (similar to obtaining any certificate with a yearly expiration date) No need to installed or stand up any caGrid specific Infrastructure or components 24

25. Using MirthConnect to Integrate with caGrid iHub provides individually deployable MirthConnect components which can invoke caBIG Grid Service iHub provides individually deployable MirthConnect components which can interact with caGrid Security Infrastructure iHub MirthConnect can expose an Inbound Grid Service Interface (deployed on a separate Tomcat) allowing caBIG/others applications to transmit messages securely using caGrid These components can be deployed on top of a MirthConnect instance and then be configured as part of any integration channel to connect to caBIG/caGrid Services and Applications 25

26. Proposed solutions for caGrid-based Integration Subject Registration Integration Scenario –Option 1: Leverage iHub’s capabilities on MirthConnect to connect to caAERS Registration Consumer Grid Interface –Option 2: caAERS Registration Consumer to be converted into a non-Grid Interface Adverse Events Integration Scenario –Option 1: Leverage iHub’s capabilities on MirthConnect to connect to caAERS Adverse Events Grid Interface –Option 2: caAERS Adverse Events Grid Service Interface to be converted into a non-Grid Interface Imaging Integration Scenario –NBIA’s Imaging Grid Service Service Interface to be converted into a non- Grid Interface –caIntegrator to be enhanced to connect to this non-grid NBIA Service Lab Results Integration Scenario –CCHC to be enhanced to transmit HL7v3 message to a non-GridInterface on the ESB Single Sign On –Leverage other SSO servers such as CAS, JSSO etc. 26