# Presentation: 233002

## caBIG CTMS Applications

- February 19 & 20

**caBIG CTMS Applications**
**Clinical Trial Management Systems**

## caBIG General Principles

- Open access, open source
- Both raw and processed data will be made available.  Patient privacy and other concerns will be respected and addressed, but will not in and of themselves preclude sharing of appropriate data.
- Software source code, use cases, designs, models, test plans, and other artifacts of the development process will be shared.
- Where possible, open source enabling technologies will be selected, and any caBIG funded development will be open source.
- Good will among participants
- caBIG Workspaces are collaborative teams, and participants are expected act accordingly.
- Debate and discussion is encouraged, but professional demeanor and tone should be the norm.

## caBIG Architectural Principles

- Data and analytic services will be made available to caBIG using uniform application programming interfaces (APIs) and appropriate standard message formats.
- The APIs and messages will be derived from common information models for biomedical data entities or objects, and will be accessible through interfaces that reflect these models.
- APIs and messages will support the delivery of data and also of accompanying metadata, in order to ensure that aggregated data sets are comparable.
- Applications will be engineered to use the common caBIG APIs.
- Standards for data exchange formats will be used.
- All systems, applications and selected standards will be documented.

## caBIG Data Standards

- Data will be described by metadata elements that conform to an accepted standard such as ISO/IEC 11179. Metadata will be leveraged to achieve data interoperability and comparability.
- Data and metadata will be constructed and drawn from appropriate vocabulary and ontology standards.
- caBIG will consume of appropriate public, open access standards where they are available.
- caBIG participants will engage in ongoing metadata development and curation activities relevant to their area of expertise.

## NCICB Approach to caBIG Compatibility: caCORE Integration

**Integrating a development effort with caCORE follows approximately three levels of "maturity", or degree:**
**Consumption of caCORE resources**
- caBIO APIs used to retrieve data: Avoid duplication of existing objects
- Create/manage common data elements using the caDSR
- Use EVS vocabulary services for terminology standards, data element creation
**Architecture Consistency**
- Middleware using technology stack compatible with caBIO
- Need to define constraints
- Set of minimum specs to be consistent with caBIO
**Architecture Integration**
- Object models merged, connected to caBIO models and packaged with caCORE releases.
- Java, SOAP, HTTP-XML APIs exposed/published (read only).
**It is okay to be at any level but the developer:**
- Should not do anything that would prevent them from getting to level 3.
- Build their system to be consistent with caCORE architecture and principles.

## Presentations Today and Tomorrow

- Various NCI attempts at caBIGifying clinical applications
- Key learnings
- Solutions available today
- Components that can be quickly made caBIG compatible
- Underlying standards and components discussion