# Presentation: 353477

## Introduction to Interoperability in the 

**Introduction to Interoperability in the **
**Cancer Biomedical Informatics Grid****TM**

**Peter A. Covitz, Ph.D.**
**Chief Operating Officer**
**National Cancer Institute **
**Center for Bioinformatics**

- Filename/RPS Number

**Notes:**
This series of introductory presentations on caBIG are all being Webcast.  
The slides will be posted on the caBIG Web site, and the Webcasts will be archived at NIH.  

## caBIGTM Introductory Seminars:  March 2006

- Topics
- caBIGTM Overview – March 13
- Overview of caBIGTM Activities for Clinical Trials and Tissue Banking – March 15
- Overview of caBIGTM Activities for Integrated Cancer Research – March 16
- caBIGTM Interoperability and  Compatibility Basics –
-                     March 17
- https://cabig.nci.nih.gov/seminars
- http://videocast.nih.gov/

- Filename/RPS Number

**Notes:**
This series of introductory presentations on caBIG are all being Webcast.  
The slides will be posted on the caBIG Web site, and the Webcasts will be archived at NIH.  

## National Cancer Institute 2015 Goal

- Eliminate suffering and death due to cancer by the year 2015

- Filename/RPS Number

**Notes:**
The goal of caBIGTM is to move the cancer research agenda forward as rapidly as possible.

## Origins of caBIGTM

**Need: **Enable investigators and research teams nationwide to combine and leverage their findings and expertise in order to meet NCI 2015 Goal.
**Strategy:** Create scalable, _actively managed_ organization that will connect members of the NCI-supported cancer enterprise by building a biomedical informatics network

- Filename/RPS Number

**Notes:**
Cancer researchers are working in isolated environments--not leveraging findings.
Researchers speak different ‘dialects’ (e.g., molecular biology and anatomical pathology).
Researchers can use one term for different concepts or different terms for the same concept.
Data are typically kept locally and are not easily shared.
The assumption is that combined efforts will move research progress along more rapidly.
caBIGTM provides the unifying infrastructure for sharing and integrating data; using common standards.

## Slide 5

- Filename/RPS Number

**Notes:**
The caBIG organization consists of “Domain Workspace” (the vertical ellipses in the diagram) that focus on informatics problems in a particular domain of cancer research
caBIG also has “Cross-Cutting Workspaces” (the horizontal bars) that integrate the the Domains together into a common framework with consistent architecture and data standards
“Strategic Workspaces” set the overall guidelines and goals for the caBIG program.

## Scenario from caBIGTM Strategic Plan

- A researcher involved in a phase II clinical trial of a new targeted therapeutic for brain tumors observes that cancers derived from one specific tissue progenitor appear to be strongly affected.
- The trial has been generating proteomic and microarray data.  The researcher would like to identify potential biochemical and signaling pathways that might be different between this cell type and other potential progenitors in cancer, deduce whether anything similar has been observed in other clinical trials involving agents known to affect these specific pathways, and identify any studies in model organisms involving tissues with similar pathway activity.

- Filename/RPS Number

**Notes:**
A key goal of caBIGTM is to create the capacity to integrate and aggregating information that has been collected at different times, in different locations, by different research groups.
All of the red colored words represent data types from such diverse sources.  Achieving the scenario described in the slide would be difficult or impossible without an integrative framework like caBIG.  

## Interoperability

- Semanticinteroperability

- Syntacticinteroperability

**Interoperability**

- ability of a system to access and use the parts or equipment of another system

- Filename/RPS Number

**Notes:**
In order to achieve caBIG’s program goals, we need to start with a clear definition of what we mean by “Interoperability”.  This definition concisely illustrates the two major components to interoperability.
Syntactic interoperability corresponds to structural aspect of the commands needed to access a remote computer resource and retrieve something from it.
Semantic interoperability corresponds to the “meaning” of the contents of that resource.  

## caBIGTM Compatibility Guidelines

**SYNTACTIC**

**caBIGTM Compatibility Guidelines**

- Filename/RPS Number

**Notes:**
caBIGTM compatibility enables integration of information across institutions, data systems and research domains.
There are three levels of compatibility:  bronze, silver, and gold (each level, respectively, providing greater compatibility).  
The Compatibility Guidelines divide syntax into programming and messaging interfaces.  
The other three categories are harder-- semantics.
Tough in biomedicine since the field has more vocabularies and many different branches of the biological sciences. There are lots of scientific terms/jargon-- created for specific purposes that are adopted over time.  These terms/jargon often do not have precise meanings.
Data elements = the description of a collected unit of data (typically it is important to know what ‘question was asked’ that prompted the collection of the data element, which instrument was used to collect the data, e.g., gene expression, or entered o form, etc.). Where did it come from?  Others must know where it came from (how/why collected; values [# or terms] and meaning).  Built from controlled terminologies.
Most scientists think of information in the context of a model of data relationships.  Therefore, Information Models are an important component to achieving caBIG compatibility.

## Model-Driven Architecture

- Filename/RPS Number

**Notes:**
Model-Driven Architecture is a design process and methodology used to create caBIG Silver compatible resources.

- Filename/RPS Number

**Notes:**
Model Driven Architecture (MDA) is a paradigm espoused by the Object Management Group, a software industry organization that maintains the standards associated with MDA.
MDA is a good fit for the life sciences, as the development of the models enables life scientists and computer scientists to work more easily together. 
MDA is also a superior design and programming methodology, as it allows for abstraction of data away from primary storage, thus adding tremendous flexibility to architectural designs, and increasing the diversity of target use cases that can be supported.

## MDA Approach

- Analyze the problem space and develop the artifacts for each scenario
- Use Cases
- Use Unified Modeling Language (UML) to standardize model representations and artifacts. Design the system by developing artifacts based on the use cases
- Class Diagram – Information Model
- Sequence Diagram – Temporal Behavior
- Use meta-model tools to generate the code

- Filename/RPS Number

**Notes:**

The MDA approach is not one of simply starting to ‘write software to solve what is thought to be the problem’; but rather focuses initially on the development of documentation; i.e., ‘use cases’ that examine what the software should do.
Use cases are then turned into models that represent the system that will be engineered.  The models are represented using one of the MDA standards, the Unified Modeling Language.  

## Limitations of MDA

- Limited expressivity for semantics
- No facility for runtime semantic metadata management

- Filename/RPS Number

## caCORE

- MDA plus a whole lot more!

- Filename/RPS Number

**Notes:**
caCORE is a suite of technologies and resources that help teams meet interoperability requirements.  It extends the MDA paradigm, adding facilities to address the limitations of MDA.

## caCORE

- Filename/RPS Number

**Notes:**
The major components of caCORE are:
Bioinformatics Objects, a model-driven middleware-based representation of data as objects.  caBIO was the first such implementation, but there are now many others in the caBIG program.
Common Data Elements, the units that make up a given model’s data representation.  Common Data Elements (CDEs) are derived from UML models and other sources, and codify the meaning and representation of each unit of data that is to be transmitted in caBIG.  The Cancer Data Standards Repository (caDSR) is the metadata registry that hosts the CDEs.
Enterprise Vocabulary Services (EVS) provide the terminology and ontology management facilities.  
Common Security Model (CSM) provides access control and authorization management capabilities. 

## Bioinformatics Objects

**Bioinformatics Objects**

- Filename/RPS Number

**Notes:**
This is a UML Class diagram.  
This is an example from basic molecular biology.  
Note that UML itself is knowledge domain-neutral, and can be used to represent any subject area.
The boxes represent the data Classes.
The rows in each box are the Attributes of a Class.  These correspond to data elements, as when a class is instantiated as a data object, the data itself exists as values for each attribute.
The arrows represent the associates between Classes.

## caBIGTM UML Models Completed and in the Works at Cancer Centers for Silver Systems

- mzXML	mass spec proteomics 		data
- scanFeatures	Proteomics
- AML 		Proteomics
- statml		Statistical markup model
- CAP		College of American 		Pathologists 			protocols for 			Breast, Lung, Prostate
- GoMiner	Text mining tool for GO
- caTISSUE	Tissue banking
- protLIMS	Laboratory Information 		Management System for 		proteomics
- BRIDG	Clinical Trials

- caBIO		General bioinformatics
- caDSR	ISO11179 metadata
- EVS		Vocabulary
- caMOD	Cancer Models
- MAGE 1.2	Microarray data
- CSM		Security
- Common	Provenance, DBxrefs
- caTIES	Pathology reports.
- gridPIR	Protein Information

- Filename/RPS Number

**Notes:**
List of UML models that are part of caBIG, developed by the NCI and by other groups in the caBIG program.
Note the broad coverage of cancer research domains.

## Cancer Data Standards Repository

- ISO/IEC 11179 Registry for Common Data Elements – units of semantic metadata
- Client for Enterprise Vocabulary: metadata constructed from controlled terminology and annotated with concept codes
- Precise specification of Classes, Attributes, Data Types, Permissible Values: **Strong typing** of data objects.
- Tools:
- _UML Loader_: automatically register UML models as metadata components
- _CDE Curation_: Fine tune metadata and constrain permissible values with data standards
- _Form Builder_: Create standards-based data collection forms
- _CDE Browser_: search and export metadata components

- Filename/RPS Number

**Notes:**
CDEs (Common Data Elements) are fundamental units of metadata.  
Reuse is important. People need to be able to  compare and aggregate.  In order to do that, there has to be an authoritative registry of what each datum means.  The caDSR provides this registry function.
Several tools make using the caDSR easier.  These tools support the loading and harmonization of CDEs from models, and also the deployment of CDEs as data collection forms.  

## Description Logic

- Preferred Name

- Synonyms

- Definition

- Relationships

- Concept Code

**Enterprise Vocabulary**

- _Description Logic_

- Filename/RPS Number

**Notes:**
The EVS provides the fundamental units of semantics used to specify data elements.  These units are “Concepts” rather than terms per se, and the overall structure is that of a thesaurus rather than a dictionary.  
Each Concept has a number of properties, including a Preferred Term and a Concept Code.  
The ability to support synonyms is particularly important, as there are many synonyms for biomedical concepts, including non-English language synonyms.  

## Semantic metadata example: Agent

**<****Agent****>**
**<****name****>****Taxol****<****/name****>**
**<****nSCNumber****>****007****<****/nSCNumber****>**
**<****/Agent****>**

- Filename/RPS Number

**Notes:**
The next few slides walk through an example of why going to all the trouble of specifying semantics is useful.  The example uses the data class “Agent”, and some data from an instance object from the class. 

## Why do you need metadata?

| Class/
Attribute | Example Object Data | CIA Metadata | NCI Metadata |
| --- | --- | --- | --- |
| Agent | 
 | A sworn intelligence agent; a spy | Chemical compound administered to a human being to treat a disease or condition, or prevent the onset of a disease or condition |
| Agent
nSCNumber | 007 | Identifier given to an intelligence agent by the National Security Council | Identifier given to chemical compound by the US Food and Drug Administration Nomenclature Standards Committee |
| Agent
name | Taxol | CIA code name given to intelligence agents | Common name of chemical compound used as an agent |

- Filename/RPS Number

**Notes:**
This is an exaggerated case/example but it makes the point that ambiguity is inherent in most kinds of data, and thus metadata is needed to eliminate the possibility of misunderstanding or misuse of data during analyses.

## Computable Interoperability

**Agent**

- name

- nSCNumber

- FDAIndID

- CTEPName

- IUPACName

**Drug**

- id

- NDCCode

- approver

- approvalDate

- fdaCode

**C1708:C41243**

**C1708:C41243**

**C1708**

**C1708**

**My model**

**Your model**

- Filename/RPS Number

**Notes:**
To achieve interoperability in the mapping of models is critical.
 Models are first mapped to a common reference terminology such as the NCI Thesaurus.  The red codes annotating the models are concept codes from the NCI Thesaurus.
The annotated models are then loaded into the caDSR, which checks the concept codes and keeps track of which elements of which models are equivalent.  
The caDSR then serves as a reference that can be used for computable interoperability

## caCORE Architecture

**Java Applications**

**Data Access**
**Objects**

**Web Application Server**

_**Interfaces**_
**Java**
**SOAP**
**XML**

**HTTP Clients**

**SOAP **
**Clients**

_**Data**_

_**Clients**_

**Perl  **
**Clients**

**Enterprise**
**Vocabulary**

**Common**
**Data**
**Elements**

_**Middleware**_

**A**
**P**
**I**

**A**
**P**
**I**

**A**
**P**
**I**

**A**
**P**
**I**

**Data **
**Access**
**Objects**

**Domain**
**Objects**
**[Gene, Disease, etc.]**

**Domain**
**Objects**
**[Gene, Disease, Agent,**
**etc.]**

**caCORE Architecture**

**Biomedical**
**Data**

**Authorization**

- Filename/RPS Number

**Notes:**
caCORE systems are n-tier, with separation of data storage (databases), data representation (objects), and application programming interfaces (APIs).  

## caCORE Software Development Kit

- Filename/RPS Number

**Notes:**
The tools used to create caCORE have been packaged and released as a kit, thus enabling groups outside the NCI to create similar types of interoperable systems.

## caCORE SDK Components

**UML Modeling Tool **(any with XMI export)
**Semantic Connector **(concept binding utility)
**UML Loader **(model registration in caDSR)
**Codegen **(middleware code generator)
**Security Adaptor **(Common Security Module)

- caCORE SDK Generates a
- caBIG Silver-Compliant System

- Filename/RPS Number

**Notes:**
The caCORE SDK requires a UML modeling tool, and comes configured to accept models generated by the tool “Enterprise Architect”.  
The other components support annotation of models with NCI Thesaurus Concepts; registration and harmonization of models in the caDSR; middlware and database code generation from the model; and attachment of security to the system generated from the model.
When used as instructed, the caCORE SDK creates a caBIG Silver-compatible system.

## From Silver to Gold:caGrid

- Filename/RPS Number

**Notes:**
Independent caBIG Silver systems are interoperable, but not directly connected to each other.  
caGrid was conceived as filling in that need, and its architecture corresponds to caBIG Gold level compatibility

**Cancer **
**Center**

**Cancer Center**

**Cancer Center**

**Cancer Center**

**Cancer Center**

**NCI**

**OTHER caBIG**
**SERVICE**
**PROVIDERS**

**OTHER**
**TOOLKITS**

- Filename/RPS Number

**Notes:**
The Gold architecture will connect independently developed caBIG Silver systems to each other.  

## Use cases not satisfied by caCORE alone

**Advertisement**
**Service Provider** composes service metadata describing the service and publishes it to grid.
**Discovery**
**Researcher** (or application developer) specifies search criteria describing a service of interest
- The research submits the discovery request to a discovery service, which identifies a list of services matching the criteria, and returns the list.
**Invocation**
**Researcher** (or application developer) instantiates the grid service and access its resources

- Filename/RPS Number

**Notes:**
caGrid provides formal electronic mechanisms for resource Advertising, Discovery, and Invocation.  

## caGrid Service-Oriented Architecture

**Grid Communication Protocol**

**Service Description**

**Service**

**Workflow**

**Service Registry**

**Security**

**Metadata  Management**

**Resource Management**

**Functions**

**Management**

**ID Resolution**

**OGSA Compliant - Service Oriented Architecture**

**Transport**

**caGrid Service-Oriented Architecture**

**Schema  Management**

- Filename/RPS Number

**Notes:**
After conducting a broad survey of technologies, the NCI arrived at Grid computing as the architecture by which caBIG Gold requirements would be achieved.  
A number of components from a variety of projects are being used, including:
 the Globus Toolkit for the basic grid framework;
caCORE for semantics and object-oriented representations; 
Open Grid Services Architecture – Data Access and Integration (OGSA-DAI) for data service specification; and 
Mobius, from Ohio State University, for schema management.  

## Grid Services

- Two types of top-level grid services defined
**Data Services: **Respond to queries and return caBIG-compatible data objects
**Analytical Services**: Accept and process caBIG data objects, then return results that are also caBIG data objects.

- Filename/RPS Number

**Notes:**
Two definitions of top-level grid services:
1.	Data services, take a query and give back the results as standardized data objects, and 
2.	Analytical services that take data in, do something with it and return caBIG data objects back. 

## Test bed Infrastructure

- caGrid 0.5 Test Bed

- Filename/RPS Number

**Notes:**
The caGrid 0.5 test bed was instantiated in September 2005, and has grown since that time.  
Nodes at different locations provide a variety of data and analytical services. 
The caGrid software itself is also available for download, and includes client components needed to access caGrid from within a Java program. 

## How can my research benefit from caBIGTM Tools?

**Everything developed by the program is open source and freely available**
**Training is available at **_**https://cabig.nci.nih.gov/training**_
**The latest versions of all the software developed as part of the project can be obtained from the caBIGTM CVS site:**
**http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/**
**Commercial-grade documentation is provided as part of the project, which will be located at the project gforge site:**
**http://gforge.nci.nih.gov **

- Filename/RPS Number

**Notes:**
All the tools developed by caBIG are freely available. 

We have a robust training program.  You can learn about it on the Web site, too.

## How can I get support for these tools?

**NCICB Applications Support will coordinate support for caBIGTM tools:**
- Live Support: Monday – Friday 8 am – 8 pm Eastern Time
- Telephone support is available Monday to Friday, 8 am – 8 pm Eastern Time, excluding government holidays.
- You may leave a message, send an email or submit a support request via the Web at any time.
- Email: **ncicb@pop.nci.nih.gov**
- Phone: **301-451-4384**
- Toll-free: **888-478-4423**
- Web: **http://ncicbsupport.nci.nih.gov**

- Filename/RPS Number

**Notes:**
We have strong support for these tools.  

## caBIGTM: Getting Involved

- To get involved with caBIGTM:
- Track caBIGTM activities on the caBIGTM website, https://cabig.nci.nih.gov/
- Attend caBIGTM Annual Meeting, April 9-11, 2006, Hyatt Regency Crystal City, Arlington, Virginia
- Learn about the existing bioinformatics infrastructure, caCORE, at http://ncicb.nci.nih.gov/NCICB/infrastructure
- Download currently available caBIGTM tools from the caBIGTM website at _https://cabig.nci.nih.gov/inventory_
- Sign up for the caBIGTM mailing list at http://list.nih.gov/archives/cabig_announce.html

- Filename/RPS Number

**Notes:**
We hope you will get involved.  As I said at the beginning, for  this infrastructure, tools, and data resources to be useful, they have to reflect the needs of the user community.  You are members of that community, and therefore you can shape the evolution of caBIG and the development of specific tools. 

To learn more about or get involved with caBIGTM, interested viewers can pursue the following options: 
track caBIGTM activities on NCI’s caBIGTM website
attend caBIGTM meetings, including our Annual Meeting, on April 9-11, 2006, in Arlington, Virginia
learn about caCORE, caBIGTM’s bioinformatics infrastructure
download some of the already available data sharing and analysis tools from the caBIGTM website, or 
sign up for the caBIGTM mailing list.

Join the listserv to receive “What’s Big this Week”, which provides weekly updates on caBIGTM.

## From Village to City

**From Village to City**

- Filename/RPS Number

**Notes:**
This map of New York City developed from south to north from an ad hoc series of neighborhoods to an increasingly ordered grid.
Improved ability to navigate the city was a result of a common street address system and infrastructure, and NYC then grew to become the world class city it is.  
caBIGTM is now approaching 14th street in terms of its development!  

## Acknowledgements

**NCI**
- The whole institute is behind caBIG!

**NCI Center for Bioinformatics**
- The staff and contractors at the NCICB are managing the daily program, and creating many of the tools described here.
- http://ncicb.nci.nih.gov

- Filename/RPS Number

## Acknowledgements – Current caGrid Team

- Ohio State University Cancer Center
- Providing Primary Technical Leadership, under Joel Saltz
- SAIC
- Booz-Allen-Hamilton
- University of Chicago Cancer Center/Argonne NL
- Georgetown/Lombardi Cancer Center
- caBIG Architecture Workspace Members

- Filename/RPS Number

## For more information, contact

- Peter Covitz, Ph.D
- Chief Operating Officer
- NCI Center for Bioinformatics
- National Cancer Institute
- National Institutes of Health, US DHHS
- 6116 Executive Blvd. - # 705
- Rockville, MD  20852
- 301-451-4385
- covitzp@mail.nih.gov

- Filename/RPS Number