# Presentation: 700059

## caBIG In Vivo Imaging

- Testbed SIG Teleconference
- 4/24/2006

## Topics

- Description of annual meeting demo
- Plans for middleware development
- Plan for RSNA Testbed demo

## caBIG 2006 Annual Meeting Technology Demonstration

## Benefits

**Remote execution of multiple CAD algorithms using **
**multiple image databases**
- Facilitate research and clinical decision support with large number of subjects and multiple CAD algorithms.
- Parameter studies, clinical and preclinical trials, etc
- Provide a client to support remote human markup of nodules
- Enable better algorithm development and validation through the use of many distributed, shared image datasets
- Support remote algorithm execution – reduce data transfer and avoid the need to transmit PHI
- Reduce overall processing time and algorithm development cycle through remote compute resource recruitment and CAD compute farms
- Scalable and open source — caGrid 1.0 based

## gridCAD Architecture

**Expose algorithms, human markup and image data as caGrid Services**

**Notes:**
Here you give an overview of the system and then describe things in detail in the following slides.

## Image Data Service

- Expose data in DICOM PACS servers as caGrid Data Service
- XML based data transfer (our own schema)
- caDSR CDE

**Notes:**
Here you give an overview of the system and then describe things in detail in the following slides.

## CAD Application Service

- caGrid middleware to wrap CAD applications with grid services
- Interact with Data Services to retrieve images
- Invoke algorithm with required inputs
- Transform and report results to results data service

**Notes:**
Here you give an overview of the system and then describe things in detail in the following slides.

## Human Markup Services

- Query a work-order queue to retrieve any new markup requests
- Interact with Data Services to retrieve images
- Capture markups and save to results data service

**Notes:**
Here you give an overview of the system and then describe things in detail in the following slides.

## User Interface

## caBIG Technologies

- caGrid 1.0
- Built on Globus Toolkit 4.0, WSRF-compliant services
- Introduce toolkit for service creation and deployment
- Dorian security management for user and service authentication and authorization
- Secure conversation (encrypted) between services and clients
- caDSR
- CIP compliant vocabulary for DICOM data elements
- CQL based query and retrieve for Data Services

**Notes:**
Here you give an overview of the system and then describe things in detail in the following slides.

## Future Direction

**Privacy**
- Just-In-Time anonymization for the image data services
**High performance data transport**
**Dynamic service deployment**
**Scaling to large number of sites, services, and vendors**

**Notes:**
Here you give an overview of the system and then describe things in detail in the following slides.

## Testbed consists of
In vivo imaging caGrid standards, 
reference middleware stack implementation supporting grid based applications
Testbed is designed to
Support each individual application
Demonstrate interoperability between applications

- Testbed consists of
*In vivo *imaging caGrid standards,
- reference middleware stack implementation supporting grid based applications
- Testbed is designed to
- Support each individual application
- Demonstrate interoperability between applications

## caBIG’s caGrid is an open infrastructure providing a set of core services and defining a set of protocol standards, communication transport mechanisms, and a series of requirements on community provided grid services
To facilitate interoperability between grid components and multi-site collaboration and resources sharing, every analytical and data service on the grid must adhere to these caGrid standards

- caBIG’s caGrid is an open infrastructure providing a set of core services and defining a set of protocol standards, communication transport mechanisms, and a series of requirements on community provided grid services
- To facilitate interoperability between grid components and multi-site collaboration and resources sharing, every analytical and data service on the grid must adhere to these caGrid standards

## Overview of caGrid

## Interoperability
First focus
Performance
Ease of use

- Interoperability
- First focus
- Performance
- Ease of use

## DICOM/HL7/IHE and caGrid interoperability layer
Bulk data transfer and dynamic algorithm deployment mechanisms
SDK to facilitate use of IVI middleware in caGrid application development
Reference Implementation
DICOM data and analytic service
Example workflow connecting these services

- DICOM/HL7/IHE and caGrid interoperability layer
- Bulk data transfer and dynamic algorithm deployment mechanisms
- SDK to facilitate use of IVI middleware in caGrid application development
- Reference Implementation
- DICOM data and analytic service
- Example workflow connecting these services

## DICOM – standard data information model,  messaging, reporting, etc, for radiology electronic medical records
HL7 – messaging (vocabulary, syntax, and API) for laboratory, clinical, adminstrative, and hospital wide information systems
IHE – specifies standard subsets of HL7 and DICOM messages to ensure interoperability between hospital information systems.  Integration profiles describe flow of information and control

Harmonization of IHE/HL7/DICOM security mechanisms with the caGrid security infrastructure will be necessary

- DICOM – standard data information model,  messaging, reporting, etc, for radiology electronic medical records
- HL7 – messaging (vocabulary, syntax, and API) for laboratory, clinical, adminstrative, and hospital wide information systems
- IHE – specifies standard subsets of HL7 and DICOM messages to ensure interoperability between hospital information systems.  Integration profiles describe flow of information and control
- Harmonization of IHE/HL7/DICOM security mechanisms with the caGrid security infrastructure will be necessary

## HL7

Initial middleware implementation will provide HL7 support AS-NEEDED for IHE integration

HL7 support includes vocabulary, schema, service API, and grid interfaces

- HL7
- Initial middleware implementation will provide HL7 support AS-NEEDED for IHE integration
- HL7 support includes vocabulary, schema, service API, and grid interfaces

- IHE
- IVI middleware will allow grid components to be incorporated in existing IHE profiles, using profile defined interfaces (HL7, DICOM, etc)
- Pure grid implementation of IHE profiles may be possible, and may be modeled as grid workflow
- Future direction include new IHE profiles that incorporate grid components explicitly

**Notes:**
IHE profiles describe flow of data and interactions, and specifies the required subset of communication protocol and vocabulary.  Therefore, integration with grid would occur at higher level compared to DICOM and HL7

## Types of interactions:
Middleware interface to present legacy DICOM software as grid services
Middleware interface to present grid resources as DICOM components
Definitions:
LD Component = Legacy DICOM Component
L2G interface – present LD as grid services
G2L interface – present grid services as LD components

- Types of interactions:
- Middleware interface to present legacy DICOM software as grid services
- Middleware interface to present grid resources as DICOM components
- Definitions:
- LD Component = Legacy DICOM Component
- L2G interface – present LD as grid services
- G2L interface – present grid services as LD components

## DICOM “items” to work with
DICOM data objects
Image
Text
Other
DICOM messages
C-FIND
C-GET
C-PUT
C-MOVE ...
Security
...

- DICOM “items” to work with
- DICOM data objects
- Image
- Text
- Other
- DICOM messages
- C-FIND
- C-GET
- C-PUT
- C-MOVE ...
- Security
- ...

## caBIG/caGrid components to be developed as related to DICOM
Vocabulary and CDE (VCDE WS, VCDE SIG, SIO SIG responsibility)
Data model in UML and xsd (VCDE WS, VCDE SIG, SIO SIG responsibility)
L2G and G2L Interfaces
Utilize vocabulary and data model from above in messaging
Specify standard API for invocation
L2G represent standard grid services – invoked over the grid, insulate DICOM communication to LD component in backend
G2L represent grid clients with DICOM API extensions – invoked locally using DICOM messaging, communicate with grid service in backend 

- caBIG/caGrid components to be developed as related to DICOM
- Vocabulary and CDE (VCDE WS, VCDE SIG, SIO SIG responsibility)
- Data model in UML and xsd (VCDE WS, VCDE SIG, SIO SIG responsibility)
- L2G and G2L Interfaces
- Utilize vocabulary and data model from above in messaging
- Specify standard API for invocation
- L2G represent standard grid services – invoked over the grid, insulate DICOM communication to LD component in backend
- G2L represent grid clients with DICOM API extensions – invoked locally using DICOM messaging, communicate with grid service in backend

## L2G and G2L interface implementations include DICOM conformance statements and requirements
For L2G, PACS and other DICOM servers meeting conformance requirements can plug-in directly, via configuration files
For G2L, workstation and analysis clients meeting conformance requirements can associate with the G2L interface and query, retrieve, and submit dicom data sets

- L2G and G2L interface implementations include DICOM conformance statements and requirements
- For L2G, PACS and other DICOM servers meeting conformance requirements can plug-in directly, via configuration files
- For G2L, workstation and analysis clients meeting conformance requirements can associate with the G2L interface and query, retrieve, and submit dicom data sets

## To promote reusability, DICOM image VCDE, data model, and services should extend generic image VCDE, data model and services
DICOM VCDE and data model should specify metadata specific to DICOM, such as acquisition parameters
Image metadata such as dimension should be represented by the generic image VCDE and data model and included
Other types of data such as PHI should be represented in separate data models and VCDE contexts but included
Some of these have been published in caDSR, such as CIP VCDE and patient information

- To promote reusability, DICOM image VCDE, data model, and services should extend generic image VCDE, data model and services
- DICOM VCDE and data model should specify metadata specific to DICOM, such as acquisition parameters
- Image metadata such as dimension should be represented by the generic image VCDE and data model and included
- Other types of data such as PHI should be represented in separate data models and VCDE contexts but included
- Some of these have been published in caDSR, such as CIP VCDE and patient information

## Will require IVI WS-wide effort to identify critical required data objects and messaging functionalities

## L2G interface to provide legacy DICOM data and service access to grid clients and other grid services
DICOM data service – L2G interface
Implement DICOM specific functions such as C-GET (retrieve), C-FIND (query), C-PUT (store)
Extend from generic Image data service, which provides image specific operations such as retrieval of regions
Image data service is extended from caGrid standard data service, which provides common basic operation such as query using CQL
DICOM analytical service – L2G interface
Extend standard caGrid analytical service
Provide standard methods of invocation
May specify standard input and output data types

- L2G interface to provide legacy DICOM data and service access to grid clients and other grid services
- DICOM data service – L2G interface
- Implement DICOM specific functions such as C-GET (retrieve), C-FIND (query), C-PUT (store)
- Extend from generic Image data service, which provides image specific operations such as retrieval of regions
- Image data service is extended from caGrid standard data service, which provides common basic operation such as query using CQL
- DICOM analytical service – L2G interface
- Extend standard caGrid analytical service
- Provide standard methods of invocation
- May specify standard input and output data types

**Notes:**
Need to expand and make clear

## G2L interface to provide grid data access to legacy DICOM components
Support basic C-* commands in DICOM messaging standard
Provide support for additional DICOM commands/messages as deemed critical by IVI community

- G2L interface to provide grid data access to legacy DICOM components
- Support basic C-* commands in DICOM messaging standard
- Provide support for additional DICOM commands/messages as deemed critical by IVI community

## Purpose is to reduce duration and latency of transport of large amount of unstructured data (i.e., no associated caBIG data model).  Examples include images, DNA and protein sequences, audio, binary files, etc
Embedding in XML is inefficient
SOAP messages must be parsed in entirety
Base64 binary embedding introduce 33% data bloat
Need to support arbitrary sized data, and potentially streaming and progressive retrieval
Need to coordinate with Architecture Workspace
Design generalized solution for caBIG
Develop specific implementation for caBIG IVI

- Purpose is to reduce duration and latency of transport of large amount of unstructured data (i.e., no associated caBIG data model).  Examples include images, DNA and protein sequences, audio, binary files, etc
- Embedding in XML is inefficient
- SOAP messages must be parsed in entirety
- Base64 binary embedding introduce 33% data bloat
- Need to support arbitrary sized data, and potentially streaming and progressive retrieval
- Need to coordinate with Architecture Workspace
- Design generalized solution for caBIG
- Develop specific implementation for caBIG IVI

## SOAP attachment
Binary data is attached rather than embedded in SOAP message
SOAP message is smaller and can be parsed faster
Attachment can potentially be read as a stream

- SOAP attachment
- Binary data is attached rather than embedded in SOAP message
- SOAP message is smaller and can be parsed faster
- Attachment can potentially be read as a stream

## Third party/Out of Band transport
Utilize external mechanism for data movement.  Examples include DICOM, GridFTP, FTP, HTTP, JPIP, WADO, P2P, etc...
Need data locator VCDE and model to specify location of data service, identifier of data, and preferred method of retrieval.
Data to be moved is described by a metadata xml schema, defined by the users and approved by VCDE WS.  This schema includes data locator schema to specify location of actual data and method of retrieval
Identifier of data is unique within at least the data service
Data service provide subset or all of the data transport mechanisms, and publishes supported data transport mechanisms as metadata of service
Client attempts preferred method of retrieval.  It uses a prioritized list of alternative retrieval methods, based on performance and other requirements, as fall backs and guarantee of retrieval
Need to ensure caBIG requirements are met, such as security

- Third party/Out of Band transport
- Utilize external mechanism for data movement.  Examples include DICOM, GridFTP, FTP, HTTP, JPIP, WADO, P2P, etc...
- Need data locator VCDE and model to specify location of data service, identifier of data, and preferred method of retrieval.
- Data to be moved is described by a metadata xml schema, defined by the users and approved by VCDE WS.  This schema includes data locator schema to specify location of actual data and method of retrieval
- Identifier of data is unique within at least the data service
- Data service provide subset or all of the data transport mechanisms, and publishes supported data transport mechanisms as metadata of service
- Client attempts preferred method of retrieval.  It uses a prioritized list of alternative retrieval methods, based on performance and other requirements, as fall backs and guarantee of retrieval
- Need to ensure caBIG requirements are met, such as security

## Goal is to reduce data movement on the grid
where large amount of data is to be processed
where sensitive data is to be processed and access to data is to be limited
Middleware implementation will also provide reference implementation for testing and demonstration
Need to coordinate with Architecture Workspace
Design generalized solution for caBIG
Develop specific implementation for caBIG IVI

- Goal is to reduce data movement on the grid
- where large amount of data is to be processed
- where sensitive data is to be processed and access to data is to be limited
- Middleware implementation will also provide reference implementation for testing and demonstration
- Need to coordinate with Architecture Workspace
- Design generalized solution for caBIG
- Develop specific implementation for caBIG IVI

## Requires remote grid service container to be available on remote machine
Middleware implementation provide functionalities to
Query service container’s hardware and software capabilities (potentially via a “capabilities” grid service that is registered with the indexing service)
Manage service packages and their requirements (in metadata) through repository service
Match grid service requirements to container capabilities (hardware, software, etc) by repository service
Package, transport, and deploy grid services to remote container
Globus team has been working on remote deployment.  Release date is not clear, however.
Remotely undeploy grid service from container and return container and system to condition prior to dynamic deployment
Remotely restart service container if necessary
Security: obtain service certificate, create user authorization, and define grid user to local user mapping

- Requires remote grid service container to be available on remote machine
- Middleware implementation provide functionalities to
- Query service container’s hardware and software capabilities (potentially via a “capabilities” grid service that is registered with the indexing service)
- Manage service packages and their requirements (in metadata) through repository service
- Match grid service requirements to container capabilities (hardware, software, etc) by repository service
- Package, transport, and deploy grid services to remote container
- Globus team has been working on remote deployment.  Release date is not clear, however.
- Remotely undeploy grid service from container and return container and system to condition prior to dynamic deployment
- Remotely restart service container if necessary
- Security: obtain service certificate, create user authorization, and define grid user to local user mapping

**Notes:**
Check with Globus Remote Deployment. – deploy with GAR.  This only handles deployment, no undeployment, which also implies the need for clear separation of services

## Performance: Dynamic Grid Service Deployment

**Performance: Dynamic Grid Service Deployment**

- Data
- Service

- Repository
- service

- 1. Locate Data Service

- Index
- service

- 2. Locate Service Container

- 3. Locate Repository

- 7. Query data

- 4. Deploy Request

- 5. Query container capability and matchmake

- 8. Invoke service with data pointer

- 9. Undeploy Request

- 10. Undeploy service

- 6. Deploy Service

- Capability
- Service

## First thoughts:
Extension of caGrid Introduce SDK tool for caBIG IVI specific applications
Support for creating DICOM interface services
Support for incorporating high performance data transport mechanisms in grid service implementation
Support for staging remote deployment algorithms

- First thoughts:
- Extension of caGrid Introduce SDK tool for caBIG IVI specific applications
- Support for creating DICOM interface services
- Support for incorporating high performance data transport mechanisms in grid service implementation
- Support for staging remote deployment algorithms

## Objective

- Use GridCAD as the motivating application and setup the demo to measure the effect of dosage on quality of readings
- Query & discover DICOM data sources (VCDE approved schemas)
- High performance Image transfer
- Interoperability with XIP and Annotation Software
- Scalability with multiple gridPACS or similar image data sources; multiple CAD systems; human markup at the RSNA site and distributed around the country

- Demonstrate the following middleware capabilities

## Architecture

- An extension of the caBIG annual demo using a similar architecture but different data transfer mechanisms (use the high performance transfer mechanism developed in the midddleware project)
- Use the XIP-lite (a scaled down version of XIP for testing and debugging) as the front end client
- Demonstrate the plugin capability of XIP-lite to show the addition of an ivi developed, lightweight annotation and markup client

## Other potential long-term demonstration ideas

- Multiple [PACS+caGRid Data services] will physically reside at the various PACS vendor booths with caBIG IVI logo
- Multiple [CAD+caGRid Analytical services] will physically reside at the various CAD vendor booths with caBIG IVI logo
- Multiple XIP workstations will be available around the RSNA floor for people to login with a RSNA user id and review, annotate and interact with this system
- Multiple Tablet PCs will be available for users to wirelessly interact with multiple  PACS+CAD systems over the grid