DRAFT of ProposedTRANSCEND Integration Architecture

March 2011

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

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

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 applications4

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

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

• Arrays• Images (Grid)

• Register Subjects• Track Subject Activities• Report Adverse Events• Reports

AnalyzeTrial Data

Collect & Track Biospecimens

RegistrationService

[1B]

AE GridService

[2A]

caTissue API [1D, 3C]

Semantic Infrastructure

caArrayService[TBD]

caAERS [3A]

caArray[1D?]

caIntegrator [1D, 2E, 3B, 3E]

Tolven(CDMS)

CCHC[1C]

RIM/CDA Service

[1A]

ClinicalNotes(CDA)

caTissue [1D, 3C]

Conduct ArrayExperiments

EMRs

Patient ClinicalCare

caBIG Services

caBIG Web Applications

Trial Sites

iSPY2 Trial Users

caAERS

Single Sign On

NBIA [2D]

PROCTCAE [2C]

ACRIN

NBIA GridService

[2D]

Images(Grid)

Patients

ReportOutcomes

• Terminologies• Common Data Elements

• Finalize AE• Report Serious AE

InputImageInformation

EMRs

RegistrationConsumerGrid [1B]

caIntegrator

Registration Service

[1B]

Subject Registrations

Trial Sites

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.

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.

3CImprove 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 ESBb.This platform will require additional caBIG specific capabilities (provided by iHub) to interact with caBIG/caGrid Services

Integration Scenarios

1. Adverse Events (AE)

9

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

Adverse Events (AE) Integration Workflow1. 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

GridService

5. Adverse

Events

6. ReportSeriousAdverse

Events

3. Convert from TRIM to caAERS

Format

4. Obtain GridCredential

NCI’s Production

Grid

Integration Scenarios

2. Subject Registrations

12

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

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

Subject Registration Integration Workflow1. 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 EMRs15

Tolven

1. AuthenticateUser

ESB(iHub)

caIntegratorcaAERS(GRID)

caTissue

2. SubjectRegistration(TRIM)

SSO

APIRegistration Consumer

Registration Service

3. Convert fromTRIM 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

Integration Scenarios

3. Lab Results

16

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 Tolven17

Lab Data Integration Workflow1. 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. TransformHL7v3 to

TRIM

6. TransmitTRIM

Message

4. Transmit HL7v3 Message (Grid)

CCHC(Sites)

CSVHL7v2

3. Obtain GridCredential

NCI’s Production

Grid

Integration Scenarios

4. Array Data

19

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

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. AuthenticateUser

5 . ArrayData

SSO

caIntegrator

3. ConfigurecaArray

Instance

EJB Service4. New ArrayData

Notification

Integration Scenarios

5. caGrid Usage

22

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

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

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

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