In Vivo Imaging Workspace

Imaging Query Formulation Developer-Phase II\
("IQ Project")

Project Plan

**Daniel L. Rubin MD, MS**

**Clinical Assistant Professor of Radiology**

**Research Scientist**

**Stanford University**

**Department of Medical Informatics**

MSOB X-215

251 Campus Drive

Stanford, CA 94305

Phone: 650-725-5693

Fax: 650-725-7944

rubin@med.stanford.edu

**David S. Channin MD**

**Associate Professor of Radiology**

**Chief, Imaging Informatics**

**Northwestern University**

**Joel H. Saltz MD, PhD**

**Professor and Chair**

**Department of Biomedical Informatics**

**Ohio State University**

**Brenda Young, BA**

**American College of Radiology Imaging Network (ACRIN)**

**American College of Radiology**

TABLE OF CONTENTS

[1. Introduction 3](#introduction)

[2. SUMMARY OF RESULTS FROM PHASE I ACTIVITIES
6](#summary-of-results-from-phase-i-activities)

[2.1 Background Context: Survey of current approaches to image query
6](#background-context-survey-of-current-approaches-to-image-query)

[2.1.1 caGrid Query Mechanism 7](#cagrid-query-mechanism)

[2.1.2 caBIG Cross Domain Data Query Projects
8](#cabig-cross-domain-data-query-projects)

[2.1.3 Summary of Existing Tools and Approaches
11](#summary-of-existing-tools-and-approaches)

[2.2 Functional Requirements: Use Cases for Image Query
12](#functional-requirements-use-cases-for-image-query)

[2.2.1 ACRIN 12](#acrin)

[2.2.2 COOPERATIVE GROUPS 14](#cooperative-groups)

[2.2.3 CVRG 15](#cvrg)

[2.2.4 NCIA 16](#ncia)

[2.2.5 SUMMARY OF USE CASES 18](#summary-of-use-cases)

[2.3 DESIGN AND PROTOTYPE 18](#design-and-prototype)

[2.3.1 AIM Data Service 19](#aim-data-service)

[2.3.2 Extended FQP and Demonstration Software
19](#extended-fqp-and-demonstration-software)

[2.3.3 Requirements of Existing caGrid DCQL and FQP
20](#requirements-of-existing-cagrid-dcql-and-fqp)

[2.3.4 Limitation of Existing caGrid DCQL and FQP
21](#limitation-of-existing-cagrid-dcql-and-fqp)

[3. PHASE II REQUIREMENTS 22](#phase-ii-requirements)

[3.1 REQUIREMENTS FOR Image Query FORMULATION, EXECUTION, AND IQ Tool
23](#requirements-for-image-query-formulation-execution-and-iq-tool)

[3.1.1 Application Ontology 23](#application-ontology)

[3.1.2 User Interface (UI) 25](#user-interface-ui)

[3.1.3 Query Formulation Engine 25](#query-formulation-engine)

[3.1.4 Query Execution Engine 28](#query-execution-engine)

[3.1.5 Security Layer 30](#security-layer)

[3.1.6 Application Programming Interface (API) Layer
30](#application-programming-interface-api-layer)

[3.1.7 Historical vs Future Data 30](#historical-vs-future-data)

# Introduction

Image query is a critical functional component of the cancer Biomedical
Informatics Grid (caBIG™) effort to create an integrated biomedical
informatics infrastructure for cancer research. In order to expedite the
cancer research community's access to key bioinformatics platforms,
effective ***query tools*** are vital in order for them to find and
retrieve the information they need. The caBIG™ informatics platform is
accruing a wealth of resources for imaging, such as the eXtensible
Imaging Platform (XIP) for researchers to analyze images and annotate
them, the Annotation and Image Markup (AIM) standards for storing image
annotations, the In Vivo Imaging Middleware (IVIM) for connectivity and
interoperability with the caBIG™ grid, and the National Cancer Imaging
Archive (NCIA) for storing vast image collections from the plethora of
cancer trials. The current resources provide the cancer community
technologies to federate these data archives, and browse and retrieve
data from them in a seamless manner over the grid. There is however a
need for techniques that will let researchers ***explore the various
caBIG resources,*** pose questions, and correlate image data with
related non-image data to formulate new hypotheses and research
directions.

With the imminent release of the caBIG™ imaging tools, there is an
emerging need for a query interface permitting users to search the
caBIG™ resources in an intuitive way. Most users will not have intimate
knowledge of database storage schemas, particular controlled
terminologies or coding schemes. However, data resources in caBIG™ are
being annotated and indexed using such terminologies. End users need
query tools to help them create queries that exploit the capability of
existing biomedical ontologies to enhance the search for images that are
annotated using such knowledge sources in the AIM and XIP projects.

The Phase I IQ project undertook several activities to define the
requirements for image query, resulting in this Phase II specification.
This document details the results of Phase I functional requirements
gathering and proposed work plan for Phase II. Specifically, Phase I
accomplished the following:

-   Compiled a list of the **questions people ask** and the **kinds of
    data elements** in various databases that are relevant. This not
    only provides a collection of use cases illustrating how people
    query images and image resources, but also identifies use cases that
    are made possible with the ability to query across multiple
    information models, such as the image metadata, outcome data, and
    AIM.

-   Surveyed the **various strategies for query processing** in caBIG™
    and related projects. This allows Phase II to be focused such that
    development not only leverages existing caBIG™ query efforts, but
    can be utilized by the wider caBIG™ community.

-   **Collected** **use cases**, which demonstrate how people want to
    query images and image resources, made possible with the ability to
    query across multiple information models, such as the image
    metadata, annotation and markup data, and outcome data.

```{=html}
<!-- -->
```
-   **Compiled a list of the questions** people commonly ask and the
    kinds of data elements in various databases that are relevant.

-   **Surveyed query execution** in caBIG™ and related projects to come
    up with a list of current approaches already in use within caBIG™ so
    that the software developed within this project will interoperate
    with other caBIG™ query efforts.

-   **Provided a demonstrable proof of concept presentation** shown at
    the Radiological Society of North America (RSNA) 2007 Annual Meeting
    as a part of the caBIG™ Imaging Workspace. Two primary scenarios
    were created:

-   Execute federated queries on the grid to *aggregate data from
    homogeneous data resources.*

-   Execute distributed queries on the grid to *join data from
    heterogeneous data resources with diverse data types*, including
    images, annotations, and non-image data.

The goal of Phase II will be to create an Imaging Query Formulation tool
which will provide an interface that automates the creation of
ontology-based queries to image resources, with delivery of a platform
and tool which we call the Image Query Tool (IQ Tool).

**The specific objectives of the Query Formulation Project Phase II will
be to:**

-   Create an **application ontology** that represents the kinds of
    information that users seek (obtained from the data collected in
    Phase I), and provides mapping from the conceptual types of
    information a user seeks to the granular data fields actually
    contained in various image-related databases that must be queried.

-   Create a **user interface** which will allow end users to (1) select
    data elements and data element values, and to combine them with
    Boolean operators; (2) allow users to pursue the query ontology to
    formulate queries directly in terms of ontology classes if desired;
    and (3) permit a "Query by Example" method of search.

-   Create a **query formulation component** that exploits knowledge in
    the ontology to expand user queries to improve recall of search, as
    well as to constrain the queries appropriately to improve the
    precision of search.

-   Create a **query execution engine** which will plan and execute the
    query that is formulated by the above-mentioned user interface and
    application ontology. These queries will be capable of running on
    caBIG™ data services---such as the NCIA, American College of
    Radiology Imaging Network (ACRIN), and the grid enabled archives of
    some of the NCI Clinical Trial Cooperative Groups. The security
    issues involved in the query execution engine will also be
    identified and addressed. Our team includes members of the in vivo
    imaging middleware development team and they have been funded to
    develop a prototype for executing federated queries that are
    relevant to the imaging workspace. We will extend their prototype in
    the development of this query execution engine.

Successful execution of the work described in the RFP will require
expertise in imaging informatics, ontology development and
representation standards, middleware and grid technologies, and query
methodologies. In particular, as the IQ Tool will need to work with
databases that utilize AIM and are accessible on caGrid.

# SUMMARY OF RESULTS FROM PHASE I ACTIVITIES

The core activities for Phase I defined the functional requirements for
the Phase II work. The Phase I work addressed the following issues to
determine requirements for the Phase II project:

1.  **BACKGROUND CONTEXT**: Survey of the current approaches to image
    query.

2.  **FUNCTIONAL REQUIREMENTS**: Use cases for how users are searching
    for images and composing queries for those searches.

3.  **DESIGN AND PROTOTYPE**: Proof-of-concept design and initial
    prototype to demonstrate that the design fulfills the functional
    requirements and that it could be useful in current query scenarios;
    also demonstrate that the design can be implemented in the prototype
    and that the prototype is able to realize a subset of the use cases.

We summarize the outcome of Phase activities for each of these tasks.

## Background Context: Survey of current approaches to image query

The first step in developing the requirements for a tool enabling users
to query image resources is to find out precisely the types of
information that users actually seek. We looked at the types of
questions people are asking and the data fields that are relevant to
their queries. We also considered queries related both to image and
clinical data.

Specifically, we surveyed the following groups and resources:

-   **Cooperative groups**: We reviewed several ongoing protocols in
    cooperative groups and research projects such as RTOG, CALGB, and
    CVRG. These protocols have query needs related to images. See
    Section 2.2 for results of exploration of use cases.

-   **ACRIN**: We worked with ACRIN to review their data warehouse
    project to understand their approach to query. This provides a very
    nice query mechanism, including a GUI for query formulation, and it
    appears promising for us to extend that interface to query images
    from federated Grid resources.

-   **NCIA**: We reviewed the NCIA image query services, which provide
    query of this image archive. We also reviewed the DICOM elements
    used by NCIA in their data model to provide us the spectrum of
    information subject to query in NCIA.

-   **caBIG:** We reviewed current query infrastructure within caBIG,
    specifically the motivation and design of CQL in caGrid. In
    addition, we reviewed several projects that exhibit similar
    "cross-domain" query requirements and examined their approaches to
    integrating data from multiple caGrid services. See Sections 2.1.1
    and for more detail

### caGrid Query Mechanism

A central goal of caBIG™ is to provide and support semantic and
syntactic interoperability of the data rsources. To promote
interoperability, caBIG requires that common vocabularies are published
in the Enterprise Vocabulary Service (EVS), the common models and common
data elements (CDE) are published in the Cancer Data Standards
Repository (caDSR). The review and publication process for the
vocabulary, model, and CDEs ensures that they are semantically
harmonized, and discoverable by end users, developers, and software
applications. To support this process, caBIG subscribes to an object
oriented domain data modeling process using UML.

caGrid, the core software infrastructure of caBIG, significantly extends
the standard web service and grid service infrastructure. As an
extension of web services, caGrid services interfaces are specified via
XML schemas which are programmatically generated from the UML domain
models. caGrid ensures that semantic and syntactic interoperability are
maintained by enforcing the use of published XML schemas and providing
an object oriented view of the grid-based data using XML-to-object
bindings. The caGrid Data Service specification further requires a
common query interface for data content using the caBIG Query Language
(CQL). All caGrid data services respond to CQL based queries and return
domain objects in XML format.

CQL (<http://www.cagrid.org/mwiki/index.php?title=Data_Services:CQL>) is
an object oriented query language. CQL allows a user to formulate a
query statement that utilizes vocabulary and CDEs defined in caBIG
domain data models. It explicitly specifies the association
relationships between classes or commond data elements, and the
containment relationships between classes and its attributes.

CQL allows filtering at the attribute level, using predicates such as
"Equal", "Less Than", "Like", based on user specified values. It also
provides support for Boolean "and" and "or" operators for grouping
attribute filters, including the containing classes. An XML
representation of CQL is show in Figure 1

![](media/image1.png){width="6.368055555555555in"
height="2.011111111111111in"}

Figure 1: an example CQL statement in XML format.

CQL provides a common mechanism for querying individual caGrid data
services. To support query across multiple data services and joining
data from related domains, caGrid also provides Distributed CQL (DCQL)
for query specification. DCQL is a distributed version of CQL to query
across multiple data services using different domain models. caGrid also
provides Federated Query Processor (FQP) for processing DCQL. Federated
Query Processor (FQP) transforms DCQL to multiple CQLs for processing by
individual caGrid data services. An example DCQL document illustrates a
cross-domain query in Figure 2.

> ![](media/image2.png){width="6.001388888888889in"
> height="3.095138888888889in"}

Figure 2 Example DCQL query statement in XML format

While caGrid data service, CQL, DCQL, and FQP together provide
standardized mechanisms for accessing strongly typed data on the grid,
several functionality extensions can greatly enhance the querying
capability of the system. The limitations of current capabilities are
discussed in Section 2.3.4.

### caBIG Cross Domain Data Query Projects

We discussed the use cases for data query (not necessarily focused on
images) with James Buntrock, who works in the Architecture workspace. He
had recently created a White Paper related to use cases for
terminologies in caBIG ("Vocabulary Services for caGrid: Strategy and
Technical Approach"). This paper outlines the need for terminology
query. However, beyond LexGrid and caDSR resources whose focus is
terminology or data element query/access, no efforts focus on *query
involving the semantics of the data values* in caBIG.

Within caBIG, several projects exist that deal specifically with
cross-domain data query and integration. Three projects are highlighted
below: caTRIP, caIntegrator, and caB2B.

**caTRIP** (see <https://cabig.nci.nih.gov/tools/caTRIP>)

> caTRIP allows users to query across a number of caBIG data services,
> join on common data elements (CDEs), and view their results in a
> user-friendly interface. Having as its initial focus the enabling of
> outcomes analysis, caTRIP allows clinicians to query across data from
> existing patients with similar characteristics to find treatments that
> were administered with success. In doing so, caTRIP can help inform
> treatment and improve patient care, as well as enable the searching of
> available tumor tissue, locating patients for clinical trials, and
> investigating the association between multiple predictors and their
> corresponding outcomes such as survival. Of importance, caTRIP relies
> on the vast array of open source caBIG applications, including (1)
> Tumor Registry, a clinical system that is used to collect endpoint
> data; (2) the cancer Text Information Extraction System (caTIES,
> https://cabig.nci.nih.gov/tools/caties), a locator of tissue resources
> that works via the extraction of clinical information from free text
> surgical pathology reports while using controlled terminologies to
> populate caBIG-compliant data structures; (3) caTissue CORE
> (https://cabig.nci.nih.gov/tools/catissuecore), a tissue bank
> repository tool for biospecimen inventory, tracking, and basic
> annotation; (4) Cancer Annotation Engine (CAE)
> (https://cabig.nci.nih.gov/tools/cae), a system for storing and
> searching pathology annotations; (5) caIntegrator
> http://gforge.nci.nih.gov/projects/caintegrator/), a tool for storing,
> querying, and analyzing translational data, including SNP data.
>
> caTRIP focuses on enabling outcome analysis to identify successful
> treatment strategies based on correlative data. It links together the
> following caGrid data services: CAE for pathology annotation
> management, caTISSUE CORE for biospecimens tracking, caTIES for
> textual information extraction from pathology reports, caIntegrator
> for accessing SNP data, and Tumor Registry for collecting endpoint
> data. caTRIP uses caGrid FQP as the distributed query engine and DCQL
> as the query language (Figure 3). It allows joining of data from these
> 5 services through shared common data elements (CDEs). caTRIP relies
> on existing CDE and vocabulary, and does not appear to support
> ontology driven queries.
>
> ![](media/image3.jpeg){width="4.416666666666667in"
> height="3.5659722222222223in"}

Figure 3. caTRIP architecture diagram

**caIntegrator**

caIntergrator supports the storage, query, and retrieval of
translational data including SNP. It provides capabilities to allow
researchers to perform queries crossing knowledge and data domain
boundaries. caIntegrator defines a "Clinical Genomics Object Model",
which is essentially an integrated, super data model. This integrated
data model allows for standardized programmatic access to the data in
the caIntegrator data system, and naturally queries that crosses the
sub-domains of the model. In addition, data is stored in a centralized
database that conforms to the integrated data model. Figure 4 shows the
architecture of the caIntegrator system. caIntegrator is used by the
Rembrandt, I-SPY, and GMDI trials. The challenge that caIntegrator faces
is how to integrate additional, new data models and data sources into
the super model in a scalable way.

> ![](media/image4.png){width="5.245138888888889in"
> height="3.3993055555555554in"}

Figure 4. Architecture diagram of caIntegrator system.

**caB2B**

We also reviewed the Cancer Bench to Bedside (caB2B) project, which
provides an interface for data and data field query. While that project
is in early stages and does not focus on image query, its user interface
may be relevant, allowing users to search for metadata fields before
searching for particular values of those fields.

caB2B project focuses primarily on microarray and the corresponding
clinical data. It supports querying caGrid data services, invoking
caGrid analytical services, and display results. The graphical user
interface allows for construction of query based on *Categories*, which
are predefined collection of attributes; *Limits*, which are conditions
or predicates that an attribute must satisfy to be considered a match;
and *Paths*, which are association between categories. The data
integration aspect of caB2B is captured via Paths, as they are computed
from CDEs in the domain models. Attributes of CDEs are identified to be
equivalent based on information nfrom caBIG EVS and caDSR, and Paths are
generated to establish linkages between attributes of CDEs and models.
Multiple paths can exist between attributes.

caB2B stores and manages the Categories, Limits, and Paths centrally in
a database. The system supports cross-domain queries based on common
caBIG CDE, and uses DCQL and FQP to transform queries for evaluation by
caGrid data services. While this system does not utilize data ontology
for formulating queries, it has significant features that relate to the
Image Query Formulation project, and its functionalities should be
examined in more details during Phase II. Figure 5 and Figure 6 show the
user interface and the architecture respectively.

> ![](media/image5.png){width="3.303472222222222in"
> height="2.3805555555555555in"}

Figure 5. caB2B user interface.

> ![](media/image6.png){width="4.797916666666667in"
> height="1.6708333333333334in"}

Figure 6. System architecture of caB2B.

### Summary of Existing Tools and Approaches

While our initial goal in the above activities was to compile a list of
the questions people ask and kinds of data elements in various databases
that are relevant, in pursuing the use cases we found that there few
questions people were asking per se; rather query was restricted to
particular data fields in the database. The existing projects that we
reviewed exhibit similar characteristics. However, their features
strongly indicate the interest and need for the ability to integrate
data with different domain models, such as images, their annotations,
and other correlative data.

We believe our survey above was sufficiently broad to be representative
of the needs of image query. The detailed information requirements are
presented in the description of use cases below. The guiding principle
for Phase II will be to provide as generic an approach as possible that
has the greatest chance of relevance to other projects in caBIG™. The
goal will be to develop tools that will interoperate with other caBIG
query efforts as well as integrate and interoperate with existing caBIG™
tools such as DCQL, Federated Query Processor, terminological service,
and caDSR. Existing user interfaces and tools such as caTRIP, caB2B, and
caIntegrator will also be evaluated for reuse.

##  Functional Requirements: Use Cases for Image Query

The specific functional requirements for the image query tool developed
in this project were gathered from a group of representative use cases
that we selected for Phase I of the project. We believe these use cases
are representative of the commonest scenarios for image query, yet be
broad enough to cover some of the less common, but important use cases.
In addition, the IQ Team investigated existing software tools and
components that can be integrated to fulfill IQ Phase II project
requirements. The goal was to come up with a list of the approaches and
components already in use within caBIG™ to ensure that 1) the query
mechanisms developed in this project will leverage and interoperate with
other caBIG™ query efforts and 2) the other caBIG™ projects where
ontology driven information query is needed can easily and effectively
reuse our methods, ontologies, and query formulation.

The following is a summary of each use case and software being used for
query that is relevant to image query.

### ACRIN

Since its inception, ACRIN has fielded numerous data access requests
because of the richness of its image archive and clinical data collected
in its clinical trials. ACRIN provided the initial core use cases (see
Table 1) based on reviewing the queries to their database for multiple
recent studies.

Table 1: Summary of ACRIN Studies and Queries

+---------------+-----------------+-----------------+-----------------+
| **Study**     | **Clinical      | **Images**      | **DICOM         |
|               | Data**          |                 | Metadata**      |
+---------------+-----------------+-----------------+-----------------+
| 6659 Prostate | Histology data  | Spectral        |                 |
|               |                 | imaging and MRI |                 |
|               |                 |                 |                 |
|               |                 | Pathology       |                 |
|               |                 | images          |                 |
+---------------+-----------------+-----------------+-----------------+
| 6659 Prostate | MRS & MRI       |                 |                 |
|               | readings by     |                 |                 |
|               | sextant along   |                 |                 |
|               | with matched    |                 |                 |
|               | pathology       |                 |                 |
|               | results.        |                 |                 |
|               | Determine the   |                 |                 |
|               | spatial         |                 |                 |
|               | relationships   |                 |                 |
|               | between         |                 |                 |
|               | sextants        |                 |                 |
+---------------+-----------------+-----------------+-----------------+
| 6652 DMIST    |                 | Digital         | X-ray technique |
| Breast        |                 | mammograms of   |                 |
|               |                 | all 335         | kVp             |
|               |                 | positive cases  |                 |
|               |                 | and all         | mAs             |
|               |                 | negative cases  |                 |
|               |                 |                 | Filter/anode    |
|               |                 |                 |                 |
|               |                 |                 | Compressed      |
|               |                 |                 | breast height   |
+---------------+-----------------+-----------------+-----------------+
| 6652 DMIST    | Pathology       | Digital images  |                 |
|               | information on  | by manufacturer |                 |
|               | lesion location |                 |                 |
|               |                 | 100 cases of    |                 |
|               | Rate of         | confirmed       |                 |
|               | detection       | cancer          |                 |
|               |                 |                 |                 |
|               | Case report     | All digital     |                 |
|               | forms           | mammography     |                 |
|               |                 | images from 200 |                 |
|               | BIRADS          | BIRADS 1 cases  |                 |
|               | classification  |                 |                 |
|               | for each cancer |                 |                 |
|               | case            |                 |                 |
|               |                 |                 |                 |
|               | Location of     |                 |                 |
|               | suspected       |                 |                 |
|               | cancer          |                 |                 |
+---------------+-----------------+-----------------+-----------------+
| 6664 CTC      | Coordinate of   |                 |                 |
|               | polyp           |                 |                 |
|               |                 |                 |                 |
|               | Location        |                 |                 |
|               |                 |                 |                 |
|               | Size            |                 |                 |
|               |                 |                 |                 |
|               | Type            |                 |                 |
+---------------+-----------------+-----------------+-----------------+
| 6657 Breast   | Tumor longest   | MRI images      |                 |
| MRI           | diameter        |                 |                 |
|               |                 |                 |                 |
|               | Morphologic     |                 |                 |
|               | pattern         |                 |                 |
+---------------+-----------------+-----------------+-----------------+
| 6654 NLST     | Nodule size     | 100 thin slice  |                 |
|               |                 | CT              |                 |
|               | Nodule type     |                 |                 |
+---------------+-----------------+-----------------+-----------------+

In addition to the use case for query, ACRIN also produced a data
warehouse query interface. This interface permits users to compose
queries using a structured metadata available as a drop-down (Error:
Reference source not found).

![](media/image7.jpeg){width="3.249212598425197in"
height="2.438976377952756in"}![](media/image8.jpeg){width="3.249212598425197in"
height="2.438976377952756in"}

### COOPERATIVE GROUPS

We reached out to a group of selected cooperative groups in developing
our use cases, including cooperative groups such as CALBG, Radiation
Therapy Oncology Group (RTOG), Image-Guided Therapy Center, and QARC
(RTOG, QARC, RPC, and ITC comprise the Advanced Technology Consortium).
The cooperative groups are a community that will be likely users of the
proposed IQ tool. They will also likely be actively engaged in the Phase
II project. The RTOG has a wealth of diverse data pertinent to image
query relevant to caBIG™, such as cancer imaging and image-guided
radiation treatment planning.

The key needs for image query in the RTOG use case is identifying
evidence on images for treatment response and to predict survival.
Querying images for change in image-based biomarkers is a common
paradigm in RTOG. An example RTOG study seeks to determine the impact of
PET on imaging endpoints: GTV, number of involved nodes, and location of
involved nodes.

RTOG provides a Web client ("ITC Remote Tool") for search, enabling
users to review target volume, contours, dose prescription or dose
hetorgeneity. Example queries for ITC Remote Tool are:

-   "Retrieve *DVH* and *CT Images* and *RT Contours where Case*=0905
    and *Protocol*=9999**"**

-   "*Find paired CT and PET/CT images and patient IDs where the number
    of involved nodes differs between CT and PET/CT image analyses*"

RTOG also provides a richer review environment --- Computational
Environment for Radiotherapy Research (CERR). CERR has been grid enabled
and an example query to retrieve objects for review could be constructed
using the following attributes:

> *archive*
>
> *tapeStandardNumber*
>
> *intercomparisonStandard*
>
> *institution*
>
> *dateCreated*
>
> *writer*
>
> *sponsorID**: \'RTOG\'***
>
> *protocolID**: \'0525\'***
>
> *subjectID**: 222***
>
> *submissionID**: 7***
>
> *timeSaved**: {\'3-Apr-2007 08:07:37\'}***

CERR also has the ability to produce metadata related to the DICOM RT
objects and this metadata can also be used in formulating exploratory
queries.

CALBG has similar needs with respect to image query---assessing disease
response.

### CVRG

The goal of the CardioVascular Research Grid (CVRG), similar to caBIG,
is to create an environment for data and algorithm sharing and
collaboration for cardiac researchers. The core infrastructure of CVRG
(CVRG-Core) facilitates the representation, storage, federation and
sharing of cardiovascular data and metadata. Organizations can join CVRG
by using the CVRG-Core infrastructure and subscribing to the common data
and resource sharing philosophy of CVRG. CVRG-Core provides caBIG
interoperable data services for managing "multi-scale" data including
SNP, transcriptional, proteomic, imaging, electrophysiological and
patient/study data. CVRG-Core will also provide APIs by which users may
add new data and analytic services that may be accessed by all users of
the CVRG.

The core objective of CVRG studies is to understand cardiovascular
disease underlying sudden cardiac death and populations for whom
implantable cardioverter-defibrillator (ICD) is indicated. The approach
is to study cardiac images and make quantitative measurements to detect
regional wall motion abnormalities and correlate the cardiac
morphologies with ECG and genomic, protein expression, and patient
outcome data. The ultimate goal is to relate the cardiac morphology with
molecular biomarkers to predict key phenotypes (inappropriate firing of
ICD and sudden cardiac death). Some example queries for the CVRG use
case are listed below:

1.  Identify subjects for further analysis (identify inappropriate
    firing of ICD)

"Find ECG, SNP, and Images for patients where ICD firing meets criteria
X".

"Find ECG and Images for patient who has SNP A"

2.  Identify high risk patients (identify risk factors for sudden
    cardiac death)

> "Find patients where ECG shows QT variability index greater than X,
> possess SNP A with genotype of GC and SNP C with genotype GT or GG,
> and has CT ejection fraction below Y"

Most of these queries currently can be accomplished only by integrating
the data across the different domains using the patient identifier. With
appropriate semantic annotation and ontology based queries, it may be
possible to formulate queries that allow for data integration via other
data attributes.

### NCIA

The National Cancer Image Archive (NCIA) collects a wealth of image
metadata as part of its imaging archive. Currently, NCIA focuses on the
storage and management of DICOM CT, PET, and MR images. The metadata
indexed by NCIA include the DICOM attributes shown below. The list of
DICOM attributes, in DICOM tag and verbose name pairs, are used in
NCIA's database schema, and is also published in the NCIA data model in
the caDSR. The NCIA model is used by the In Vivo Imaging Middleware
DICOM Data Service and NCIA's own caGrid service interface. As described
in Section 2.1.1, the NCIA data model defines the information that can
be queried in the DICOM Data Service and the NCIA Data Service using CQL
as the query language.

1\. (0x0008,0x0008) ImageType

2\. (0x0008,0x0016) SOPClassUID

3\. (0x0008,0x0018) SOPInstanceUID

4\. (0x0008,0x0020) StudyDate

5\. (0x0008,0x0021) SeriesDate

6\. (0x0008,0x0022) AcquisitionDate

7\. (0x0008,0x0023) ContentDate

8\. (0x0008,0x002a) AcquisitionDateTime

9\. (0x0008,0x0030) StudyTime

10\. (0x0008,0x0032) AcquisitionTime

11\. (0x0008,0x0033) ContentTime

12\. (0x0008,0x0060) Modality

13\. (0x0008,0x0070) Manufacturer

14\. (0x0008,0x0080) InstitutionName

15\. (0x0008,0x1030) StudyDescription

16\. (0x0008,0x103e) SeriesDescription

17\. (0x0008,0x1080) AdmittingDiagnosesDescription

18\. (0x0008,0x1084) AdmittingDiagnosesCodeSequence

19\. (0x0008,0x1090) ManufacturerModelName

20\. (0x0008,0x2218) AnatomicRegionSequence

21\. (0x0010,0x0010) PatientName

22\. (0x0010,0x0020) PatientID

23\. (0x0010,0x0030) PatientBirthDate

24\. (0x0010,0x0040) PatientSex

25\. (0x0010,0x1010) PatientAge

26\. (0x0010,0x1020) PatientSize

27\. (0x0010,0x1030) PatientWeight

28\. (0x0010,0x2160) EthnicGroup

29\. (0x0010,0x2180) Occupation

30\. (0x0010,0x21b0) AdditionalPatientHistory

31\. (0x0012,0x0010) ClinicalTrialSponsorName

32\. (0x0012,0x0020) ClinicalTrialProtocolID

33\. (0x0012,0x0021) ClinicalTrialProtocolName

34\. (0x0012,0x0030) ClinicalTrialSiteID

35\. (0x0012,0x0031) ClinicalTrialSiteName

36\. (0x0012,0x0040) ClinicalTrialSubjectID

37\. (0x0012,0x0042) ClinicalTrialSubjectReadingID

38\. (0x0012,0x0050) ClinicalTrialTimePointID

39\. (0x0012,0x0051) ClinicalTrialTimePointDescription

40\. (0x0012,0x0060) ClinicalTrialCoordinatingCenterName

41\. (0x0018,0x0010) ContrastBolusAgent

42\. (0x0018,0x0015) BodyPartExamined

43\. (0x0018,0x0022) ScanOptions

44\. (0x0018,0x0050) SliceThickness

45\. (0x0018,0x0060) KVP

46\. (0x0018,0x0081) EchoTime

47\. (0x0018,0x0090) DataCollectionDiameter

48\. (0x0018,0x1000) DeviceSerialNumber

49\. (0x0018,0x1010) SecondaryCaptureDeviceID

50\. (0x0018,0x1020) SoftwareVersion

51\. (0x0018,0x1030) ProtocolName

52\. (0x0018,0x1040) ContrastBolusRoute

53\. (0x0018,0x1100) ReconstructionDiameter

54\. (0x0018,0x1110) DistanceSourceToDetector

55\. (0x0018,0x1111) DistanceSourceToPatient

56\. (0x0018,0x1120) GantryDetectorTilt

57\. (0x0018,0x1150) ExposureTime

58\. (0x0018,0x1151) XrayTubeCurrent

59\. (0x0018,0x1152) Exposure

60\. (0x0018,0x1153) ExposureInuAs

61\. (0x0018,0x1190) FocalSpot

62\. (0x0018,0x1210) ConvolutionKernel

63\. (0x0018,0x1310) AcquisitionMatrix

64\. (0x0018,0x5100) PatientPosition

65\. (0x0018,0x9305) RevolutionTime

66\. (0x0018,0x9306) SingleCollimationWidth

67\. (0x0018,0x9307) TotalCollimationWidth

68\. (0x0018,0x9309) TableSpeed

69\. (0x0018,0x9310) TableFeedPerRotation

70\. (0x0018,0x9311) SpiralPitchFactor

71\. (0x0020,0x000d) StudyInstanceUID

72\. (0x0020,0x000e) SeriesInstanceUID

73\. (0x0020,0x0010) StudyID

74\. (0x0020,0x0011) SeriesNumber

75\. (0x0020,0x0012) AcquisitionNumber

76\. (0x0020,0x0013) InstanceNumber

77\. (0x0020,0x0032) ImagePositionPatient

78\. (0x0020,0x0037) ImageOrientationPatient

79\. (0x0020,0x0052) FrameOfReferenceUID

80\. (0x0020,0x0060) Laterality

81\. (0x0020,0x0062) ImageLaterality

82\. (0x0020,0x0200) SynchronizationFrameOfReferenceUID

83\. (0x0020,0x1041) SliceLocation

84\. (0x0020,0x4000) ImageComments

85\. (0x0028,0x0010) Rows

86\. (0x0028,0x0011) Columns

87\. (0x0028,0x0030) PixelSpacing

88\. (0x0028,0x2110) LossyImageCompression

89\. (0x0088,0x0140) StorageMediaFileSetUID

### SUMMARY OF USE CASES

We came up with the following *typical queries* that we think most
people would want:

1.  Get me all images in NCIA that are part of the RTOG 0522 study (or
    other study)

2.  Of those, find me all of those that have PET/CT

3.  Where are reports and measurements stored? Must deal with existing
    data and put that into AIM. Going forward people will annotate RTOG
    studies and save in AIM server.

4.  Find images that have no annotations; find annotations showing \>20%
    growth in disease

5.  Get all images where AIM annotations show progression in disease

In addition to these general types of queries, there are higher-level
\*questions\* that people have about these clinical trials that a series
of queries would need to be able to answer:

1)  What is predictive value of PET/CT?

2)  Does pre-treatment PET correlate with (and predict) disease-free
    survival and lack of recurrence or particular surgical findings of
    the disease? (To answer this, we need to query AIM annotations on
    PET images as well as non-image clinical data)

3)  Do post-treatment PET findings correlate with (and predict) the
    nodal response and nodal relapse in patients? (To answer that, we
    could probably simply query AIM annotations on PETs and CTs.

[]{.mark}

[]{.mark}

## DESIGN AND PROTOTYPE

To illustrate the challenges and benefits of cross-domain data query and
integration, we developed a demonstration project focused on supporting
queries such as \"Find all AIM annotations related to a specified set of
patients\" and \"Find the AIM annotations located at the upper right lob
and created by a certain radiologist for a certain study\". The query
integrates AIM and DICOM data formats. For this prototype, we utilize
the existing DICOM Data Service from the caBIG In Vivo Imaging
Middleware as DICOM data source. We have also developed a new prototype
AIM Data Service for storage and management of AIM XML documents, an
extended version of the caGrid FQP, and a client application to
demonstrate the query use case.

### AIM Data Service

A central component of the prototype is the Annotation and Image Markup
(AIM) data service. AIM documents contain the annotations that describe
features and observations in the images. An example annotation may be a
RECIST longest diameter measurement.

The AIM project defines the AIM data model, whose conforming data may be
represented as XML, DICOM SR, or HL7 CDA documents. For the
demonstration of federated query, we have created an AIM Data Service
using the XML Data Service Extension jointly developed for the In Vivo
Imaging Middleware, Cardiovascular Research Grid, and caGrid. The AIM
Data Service supports the storage and retrieval of XML AIM documents.
The documents are stored natively in a XML database. The AIM data
service provides the grid service interface to support query and
retrieval of the AIM XML using CQL as the query language.

### Extended FQP and Demonstration Software

Our work involved leveraging the existing federated querying processing
(FQP) infrastructure available in caGrid for federating remote AIM and
DICOM data services on the grid. This FQP infrastructure provides the
means to execute distributed queries over multiple data services with
potentially different data models and to make data aggregations and
joins over the results generated by the services. FQP uses DCQL for
query specification.

Our application of this infrastructure is composed of five pieces: an
FQP service, an FQP result service, an FQP client GUI, one or more DICOM
data services, and one or more AIM data services. Currently, using this
infrastructure, it is possible to execute federated queries that will
retrieve AIM annotations that are restricted by specified AIM and DICOM
attribute values.

![](media/image9.jpeg){width="5.364583333333333in"
height="2.790277777777778in"}

Figure 7. Sequence of events during a DCQL query.

In our infrastructure, the execution of a sample DCQL query that targets
certain AIM objects is as follows: The user sets a number of DICOM and
AIM object attributes using the FQP client GUI. The client automatically
translates this selection into a DCQL query. The query is submitted to
an FQP service, which will orchestrate the query execution. The FQP
service converts the received query into a CQL query that will target a
specific set of DICOM objects based on the attributes selected by the
user. This query is executed on a DICOM data service and the DICOM
object results are returned to the FQP service that initiated the query.
Figure 7 depicts these steps. These results are used to create a second
CQL query that will query an AIM data service and retrieve the target
AIM objects matching the criteria specified by the client. The retrieved
AIM objects are temporarily stored in the FQP result service and then
can be retrieved by the client (Figure 8)

![](media/image10.png){width="4.8694444444444445in"
height="3.411111111111111in"}

Figure 8. Federated query client user interface

### Requirements of Existing caGrid DCQL and FQP

For correct integration of the FQP infrastructure with caGrid services,
we identified three requirements on the individual query processor of
the data services. First, the query processor must fully implement the
CQL specification and be able to return distinct attribute values in
response to a query. This can be done by implementing the queryModifier
methods on the service side.

Second, the query processors must support the \"OR\" logical operation.
This is used to limit the set of possible attribute values when making
joins between multiple data models.

Finally, "IS_NULL" and "IS_NOT_NULL" attribute predicates must be
supported. When a data service returns an empty result set, the second
CQL query is constructed with a Boolean "AND" of these these two
predicates, which evaluates to false and ensures that the overall DCQL
query is evaluated to an empty set.

### Limitation of Existing caGrid DCQL and FQP

Currently, DCQL supports only one object type as the return type. This
limits the query to a filter operation where the search results is
filtered by a foreign attribute that exists in a different domain model.
The join attribute serves to link the two domain models. The limitation
of returning only a single type of object means that to perform a true
join operation, where both types of objects are required, the objects of
different types must be retrieved separately using separate DCQL
queries.

Other limitations of DCQL include the support of a single join
attribute. This precludes the formulation of queries where two domain
objects are joined when both attributes A and B are equivalent. DCQL and
FQP currently also supports joining attributes using only the "EQUAL"
predicate. Federated queries with join operation involving range queries
therefore are not possible currently. Finally, there is currently no
explicit enforcement that the join attributes of the two domain models
are semantically equivalent or even related. The quality and meaning of
the query result therefore is suspect.

In future extension to DCQL and FQP, several features therefore have
been identified as beneficial: support for object tuples with
heterogeneous types; support for multiple join attributes; support for
joins using predicates in addition to EQUAL; and enforcing semantic
meaningful joining of attributes.

# PHASE II REQUIREMENTS

![](media/image11.png){width="1.689763779527559in"
height="1.1625984251968504in"}![](media/image12.png){width="0.6173228346456693in"
height="0.6043307086614174in"}![](media/image13.png){width="0.7570866141732283in"
height="0.7708661417322835in"}![](media/image14.png){width="0.5708661417322834in"
height="0.5708661417322834in"}![](media/image15.png){width="0.6535433070866141in"
height="2.6401574803149606in"}Based on our survey of query approaches
and use cases, we have compiled the following requirements for Phase II
of the IQ project.

## REQUIREMENTS FOR Image Query FORMULATION, EXECUTION, AND IQ Tool

In this portion of the project, we will specify the key components of
the IQ Tool and the functional requirements necessary for each component
in order to implement a working system. Moreover, in this part of the
project, we will describe exactly what the whole software stack will
look like in order to support image query. This will clarify the
requirements for Phase II of this project and set the stage for a smooth
transition into executing that phase of the work.

The following are the core components of the IQ Tool whose functional
requirements will be compiled in Phase I, and that will be developed and
implemented in Phase II of this project.

-   Application ontology for image query

-   User interface

-   Query formulation engine

-   Query execution engine

-   Security layer

-   Application programming interface layer

An architecture diagram for the IQ Tool showing these components and how
they relate to each other is shown in Error: Reference source not found.
Users interact with the IQ Tool via the User Interface (application
developers can interact with these components via an API Layer). The
User Interface enables the user to compose queries to search image
databases on the Grid using intuitive paradigms that guide the user in
composing an ontology-based query. The User Interface accomplishes its
task by interacting with the Query Formulation Engine, a component that
accesses an Application Ontology for Query in order to create
ontology-based queries. The output from the Query Formulation Engine is
a query graph (see Section 3.3.1 and Error: Reference source not found),
an abstract representation of the user query in a form that can be
translated into different implementing query languages, such as SQL,
OQL, or others. The Query Execution Engine performs this translation and
executes the query on the Grid, returning results to the user. The
execution engine also accesses a Security Layer to take into account
access privileges and other data security issues.

Below, we will describe our methods and considerations for developing
our design and prototype (Task 2.3), which will address each of these
components.

### Application Ontology 

Our strategy for addressing the challenges of language (such as synonymy
and polysemy described in Section 1) and for matching user information
needs to the ontology terms used to annotate caBIG™ image resources is
to use ontologies for creating user queries. Ontologies provide two key
benefits in terms of query formulation: (1) they are declarative
structures that make the knowledge needed by applications explicit, and
(2) they can be used to map between different resources, provided that
entities in those resources are each described using ontologies. Many of
the language issues related to a query can be resolved by putting the
knowledge needed to resolve synonymy, polysemy, and other issues into an
ontology. Then, when a user uses particular search terms, they can be
mapped to the canonical form using the ontology as a knowledge source.
For example, if a user enters a search term "hepatic carcinoma," then
synonymous search terms such as "heptocellular carcinoma" and "hepatoma"
can be included in the search to increase coverage. Hierarchical
relations can also be exploited to broaden the search or to narrow it by
searching on parents or children of search terms, respectively. Thus, if
a user searched for "pheochromocytoma," the search could be expanded to
include terms such as "adrenal medullary neoplasms" if a broader search
is desired.

The requirements for the ontology for query will be specified in this
part of the project. Those requirements will include the need to
represent the kinds of information that users seek (obtained from Task
2.1 and Task 2.2; Section 3.1 and 3.2 above), and the granular data
fields actually contained in various image-related databases.
Requirements will be gathered to specify how ontology will provide a
mapping from the conceptual types of information a user seeks to the
low-level data fields needed to be queried. Thus, this task will require
a survey of existing metadata related to imaging so mappings from the
ontology to existing databases (such as ACRIN, Section 3.2) can be
established. In addition, a survey of the existing AIM model will be
necessary because AIM specifies the metadata associated with images
which will be subject of image search. Relevant components of AIM for
the image query ontology could include regions of interest on images
associated with annotations taken from ontologies and descriptive
metadata, such as anatomy, pathology, and observed characteristics seen
on images. Our team is particularly capable of ontology and AIM metadata
aspects of the project because in addition to ontology expertise, it
contains both of the AIM lead investigators.

Another component of this task is to evaluate existing tools that have
search functionality to reconcile the ontology to information models
they use. For example, the Freestyle tool is being developed to find
Common Data Elements (CDEs).

The ontologies used for query formulation would also need to be stored,
managed, and retrieved. Protégé provides programmatic access to
ontological information, and is a widely adopted tool. The BioPortal
ontology repository
([http://bioportal.bioontology.org](http://bioportal.bioontology.org/))
will be used for this purpose.

The ontology will also provide the information needed to feed the user
interface (Section 3.3.2). The user will not actually see the raw
ontology, but it will provide the knowledge necessary to the application
to enable users to choose attributes and values for those attributes
that will enable their search; all those parameters and values will be
obtained from the ontology. The application ontology will organize and
specify all the elements that can be queried. The ontology will organize
the elements and specify the meaning of the elements so that users can
see related elements.

We will specify the approaches to be followed in creating the ontologies
for this project. Ontologies must be robust in applications such as
this, as they contribute the core knowledge needed by the application.
Our methodology will follow best practices in ontology design \[1\]. Our
team has developed many ontologies using the methodology described above
in a variety of biomedical domains, including radiology. Recently,
members of our Northwestern and Stanford teams collaborated to create an
ontology of radiology procedural knowledge to enable integration of
information for PACS systems \[1\]. The ontology-building tasks in this
work are similar to that which will be required in this RFP, in that we
identified use cases, a target domain, and created ontologies to satisfy
the use cases.

### User Interface (UI)

Most users know little about ontologies (and probably would prefer not
to know about them since they are complex). The UI must be intuitive and
easy to use. Its core functional requirement is that it enables users to
(1) browse image resources to get a sense for the types of data they
contain, and (2) search image resources for specific types of images or
image results. The UI should exploit the ontology in enabling the user
to broaden and/or narrow their search for caBIG image resources. Because
the imaging resources are indexed using ontologies, and users are
unlikely to know the terms that are used for indexing, the UI must
provide a seamless mechanism to map from a user's intuitive queries and
ontology-based queries. This could be accomplished in a variety of ways,
such as providing options to the user to expand free-text queries using
the ontology, or providing a direct ontology-oriented method of
constructing the queries in the first place.

There are several different requirements for designing the UI to
accomplish the above needs. First, the UI could allow users to select
data elements from term lists that are filtered according to the
context---the type of information the user is seeking. In this manner,
they need not peruse a huge and complex ontology. Second, the UI should
permit users to formulate more complex ontology-based queries, using
data elements and values of those elements. The UI should permit the
user to combine query elements with Boolean operators. The user will see
a form with various types of fields with drop-down boxes, perhaps a tool
palette. The ultimate goal will be to reduce complexity of query
formulation for the user.

The ultimate UI created in this project should be reconciled with other
UIs used in caBIG, such as that being used by NCIA and other image
resources. The UI design should support creating libraries of queries,
and allow users to save their queries. The UI may incorporate components
from existing tools that has cross-domain query capability, such as
caTRIP and caB2B.

### Query Formulation Engine 

Query Formulation Engine will translate user queries that are formulated
using the IQ Tool UI into an ontology-based query graph. A query graph
is an information structure that conveys the key components of user
query needed to execute it, independent of the specific language used to
implement that query. An example query graph is shown in Error:
Reference source not found.

These requirements specify how researchers and other users query images
and discover and query associated data. Query formulation will support
the following types of queries:

-   **Exact term query**: Find images and data containing specified
    metadata whose values exactly match the term(s) in the user query.

-   **Concept-based query**: Map the user's query to terms in ontologies
    and controlled terminologies ("concepts"), and then search for
    resources indexed with those concepts.

-   **Query expansion by synonym**: Process a user query to find terms
    that are synonymous with other terms, and use the collected list of
    synonyms to expand the user query in searching for indexed data
    resources.

-   **Query expansion by abstraction**: Perform the prerequisite
    processing to map user queries to concepts (as in the concept-based
    query type above), but instead of searching on the concepts, search
    on parents of those concepts (this is the same as hypernym
    searching).

-   **Query expansion by progressive refinement**: Perform the
    prerequisite processing to map user queries to concepts (as in the
    concept-based query type above), present the children of those
    concepts to allow the user to refine and construct new queries, and
    search using the new queries (this is the same as hyponym
    searching).

-   **Boolean query**: Enable users to combine search terms with Boolean
    operators AND, OR and NOT.

-   **Query by example**: Enable users to search for data based on an
    example in the form of a "graphical" query language that uses visual
    views of potential query fields that the user partially fills out in
    order to initiate a search.

-   **Correlative query:** Enable users to construct queries using terms
    from multiple ontologies, and execute the queries on services that
    conform to different data domains and models.

An advantage of representing the query as a query graph is that it maps
very nicely to ontologies that are used to compose it. Specifically, the
graph contains entities (ovals as in Error: Reference source not
found)---the "things" that exist in biomedical reality, and relations
between entities (the lines connecting ovals in Error: Reference source
not found). Another advantage of adopting a query graph is that we can
use this paradigm to implement the Query by Example functionality
required by this RFP---the user composes a graphical query with
partially-filled values and submits that for processing. All data that
match the graphical search pattern will be returned.

A third advantage of the query graph is that it provides a computable
representation of the query that can be translated into many different
specific query syntaxes. The key advantage of the query graph is that it
provides a mechanism to compose a user query independent of the query
syntax, enabling interoperability amongst systems that may use different
query syntaxes and enabling the IQ Tool to use different query execution
engines in the future.

The query graph will be created by the IQ tool after the user interacts
with the UI to formulate the query. Once the query graph is created, it
will be submitted to the query execution engine (Section 3.3.1) to
search all caBIG™ data services supporting this query mechanism on the
grid. Any data resource that is compliant with caBIG™ data services,
including image and non-image data services, will be able to be queried
through this query mechanism, now as well as in the future. Thus, this
will be a scaleable method for image query. . The ACRIN use case will be
particularly advantageous to develop as a queryable resource, because a
subset of ACRIN data will be accessible via caGrid data service
interface. This data service interface is provided via the caGrid
enabled NCIA instance running at ACRIN.

If new data types become available subsequent to implementation of this
project, the application ontology would need to be updated. The IQ
system will be designed to minimize the impacts of and facilitate these
ontological updates. However, this would be a maintenance operation, not
in scope for this project, though it would need to be addressed and
taken up by those maintaining the project once it is deployed.

### Query Execution Engine 

Once user queries are formulated in terms of an ontology-based query
graph, this knowledge structure needs to be interpreted properly in
order to connect the diverse data sources to which the query applies,
and pertinent data must then be retrieved. We call these steps query
execution. Specifically, query execution includes the following steps:

1.  **Query Validation**. The ontology based query tree is analyzed for
    validity in the caBIG™ environment. The concepts in the query tree
    are mapped to terms in caBIG™ EVS, and CDEs and models related to
    the concepts are identified from the caDSR. Unmappable ontological
    concepts in the query tree indicate problems in the query tree,
    requiring user intervention.

2.  **Query Translation**. The ontology-based query graph is converted
    into a query statement in DCQL form. The translation is based on the
    terms, CDEs, and models discovered from EVS and caDSR from the
    previous step. The Query Execution Engine will need to access the
    ontology to perform the translation. Multiple queries involving
    different models may result from the translation process as a term
    may be mapped to multiple models.

3.  **Query Planning and Optimization.** The CQL query statement is
    simplified and optimized based on the data models that have been
    identified to be involved in the query. Model attributes and
    associations are grouped according to the models to which they
    belong. *A priori* information may be injected to facilitate query
    optimization, such as the size of expected query result, in order to
    maximize query performance and/or minimize data movement.

4.  **Query Processing.** The optimized DCQL query statement is then
    executed either using a local caGrid Federated Query engine or a
    remote caGrid Federated Query Service, and the results are returned
    to the user.

5.  **Result Aggregation.** The result of the query from multiple data
    services will need to be aggregated into an efficient storage
    structure for return to the user. The structure will need to
    maintain join relationships while minimizing data replication and
    facilitate ease of data access.

The Query Execution Engine as described above is general in principle,
and can potentially be used for distributed and federated query of all
silver compliant, caGrid-based services. In the primary anticipated use
case of federated query on DICOM Data Service and AIM Data Service, the
DICOM Data Service will present the image metadata using the NCIA DICOM
data model, and the AIM Data Service will present the data via the AIM
data model. While the services may store the images and AIM objects
using different storage formats and database mechanisms, the grid
services present the standard interfaces conforming to the NCIA and AIM
models. The Query Execution Engine constructs the DCQL query statement
based on the caBIG™ accepted models and executes the queries using the
standard, common DICOM and AIM Data Service interfaces.

Preliminary investigation in the distributed and federated query for
DICOM image data indicates that there are several areas that would
require modifications and additional development. DCQL supports queries
with a single, strongly typed object type for the query result, which
must be defined during the construction of the DCQL statement. There is
no support for tuples of objects with different data types. One
consequence is that the DCQL query is performed more similar to a filter
operation, using foreign attributes as filters, rather than a true join
operation. The results must be joined by the client application post
query. Another consequence of this restriction is that a typical join
operation would necessitate multiple query passes. For example, if we
wish to retrieve images where the annotations satisfy a certain criteria
and display the images with annotations, then the current caGrid
infrastructure will require us to execute two queries. The first query
will retrieve only those images which have the annotations satisfying
our query criteria. The second query will retrieve the qualified
annotations themselves. For efficient operation of the IQ tool, the
caGrid Federated Query Processing Infrastructure and DCQL will need to
be modified and extended to support multiple data type results and true
join. In addition, the performance and scalability of the Federated
Query Processing Infrastructure will need to be evaluated and
potentially improved. Extension of the caGrid federated query processing
infrastructure may include:

-   Support for sequence of queries

-   Performance optimization via data model aware query planning

-   Efficient data join operation

-   Support for multiple, aggregated data types in the result

-   Potential optimization in the caGrid infrastructure for efficient
    querying of data services

A second challenge that was discovered during the preliminary
investigation is that DICOM does not support multiple values in a query,
which is equivalent to the OR Boolean operation for attribute value
filtering. For example, it is not possible to construct a DICOM C_FIND
messages to query for *all images with PatientName=JohnDoe **OR**
PatientName=JaneDoe*. This query needs to be decomposed into 2 C_FIND
operations. A scalable approach needs to be devised to address this
limitation for the IQ toolkit. Similarly, existing data repositories
such as QARC, ACRIN, and NCIA may require repository-size modification
to support query and retrieve image and non-image datasets efficiently
for IQ project use cases.

### Security Layer 

> Security for distributed and federated query formulation and execution
> follow the same guidelines and policies as those for security for
> individual data resources. Security will be addressed in two aspects:
> authentication and authorization.
>
> Authentication includes user authentication and service
> authentication. For user authentication, we will leverage the Dorian
> authentication service in the caGrid GAARDS infrastructure. Dorian
> provides grid-based authentication and credential management. The user
> will log in through the Query Formulation UI, which in turn
> authenticates the user against the Dorian service. Service
> authentication involves using a host-based certificate to ensure that
> the UI and the Query Execution Engine are communicating with
> authenticated data services.
>
> Proper authorization will require that the administrators for each
> data service properly configure role-based access to the data service,
> the query operation, and the data instances managed by the service. In
> addition, the Query Execution Engine must properly delegate the user's
> credential to each data service in order for the data services to
> properly authorize and log data access.
>
> A functionality and corresponding policy that will need to be designed
> during the execution of the project is how to handle a failure in
> authorization. An incomplete query may generate incomplete and even
> erroneous results, which may lead to incorrect conclusions during
> interpretation. Proper procedure for handling these exceptions will be
> critical.

### Application Programming Interface (API) Layer 

As mentioned earlier in the proposal, the paradigm of querying data
resources is common to caBIG and is applicable to other caBIG projects.
To enable interoperability of our query platform with other caBIG
projects now and in the future, we will provide an API Layer to enable
developers to access the core functionality of the IQ system. In
addition, this API will enable developers who want to create
applications that use ontology-based query to integrate this
functionality into their systems. For example, we anticipate that XIP
would integrate image query into its platform by wrapping the IQ Tool
using this API.

### Historical vs Future Data

The Phase II work needs to address dealing with historical and future
data. For historical data, it will be necessary to find out how current
source data is stored. That activity would point to a way to convert
historical data to AIM. An alternative would be to create data services
that IQ can talk to. For future data, AIM will be used for annotating
data, so IQ-compliance is assured.

Other Design Considerations

Software Development

Though no software will be created in Phase I of this project, the
requirements set forth for Phase II will include a stipulation that all
software to be developed will be created in compliance with caBIG
principles of Open Source / Open Access, Open Development and
Federation.

All software will be developed according to the caBIG Compatibility
Guidelines (version 2, July 2005). We intend the software developed to
be of Silver level maturity.

Vocabularies and Ontologies

All of the concepts develop in the context of the AIM ontologies will be
reconciled with the EVS. This process will entail searching EVS for
existing terms that can be reused in our ontologies before creating new
ontology terms. If existing terms are located in EVS, they will be
included in our ontologies with the appropriate source name and unique
identifiers to serve as back-references to the source terminology. If
there are no existing terms in EVS required by our ontologies, we will
create new terms and submit them for consideration by NCI for
incorporation into EVS.

Common Data Elements

Any common data elements developed will be reconciled with caDSR. This
process will entail searching caDSR for any existing CDEs (if
applicable) that need to be created in this project. If a CDE already
exists in caDSR, then it will be used instead of creating a new CDE, and
the appropriate identifier and source for the CDE will be recorded. If
there are no existing CDEs, we will create new CDEs and submit them to
NCI for consideration to be added to caDSR.

Information Models

Based on the content of the query ontologies developed in this project
and in reconciliation with other pertinent ontologies/terminologies, we
will create an information model for representing user queries. We will
use Enterprise Architect (Sparx Systems Pty Ltd, Creswick, Victoria,
Australia) to produce object-oriented query models expressed in UML as
class diagrams and as XMI files. The Enterprise Architect software
package provides unified modeling language (UML) tools and manages
detailed requirements, modeling and analysis, generating and importing
source code, generating and importing database schema, generating and
importing XML schema, creating component and deployment models, tracking
changes and managing tests. These files shall be delivered to the GForge
site.

***caGrid Data Services***

For this project, the primary goal is to integrate Image related
annotations and metadata to the images. A requirement is ability to
interact with data services in a standard way. For phase II of the Image
Query project, the focus will be the ontology-driven query of caGrid
based Data Services that support CQL as the standard query language.
Phase II project will need to support DICOM centric image data services
that utilize the NCIA data model, as well as annotation data services
that uses the AIM data model.

***caGrid Enhancements***

To support query execution against caGrid data services, CQL and DCQL
may need to be extended as described in Section 2.3.4, and the Federate
Query Processor may also need to be enhanced.