Notice: This application will enforce Multi-factor authentication (MFA) for NIH users beginning the evening of Wed Aug 3rd.
NIH | National Cancer Institute | NCI Wiki  

Document Information

Author: Bilal Elahi
Email: elahib@mail.nih.gov
Team: caDSR
Contract: N/A
Client: NCI CBIIT
National Institutes of Health
US Department of Health and Human Services

Contents of this Page

Sign off

Date

Role

CBIIT or Stakeholder Organization

The purpose of this document is to collect, analyze, and define high-level needs and features of the National Cancer Institute Center for Biomedical Informatics and Information Technology (NCI CBIIT) BRIDG 2.1 Release. This document focuses on the functionalities proposed by the product stakeholders and target users in order to make it a better product. The use case and supplementary specifications document will detail how the framework will fulfill these needs.

Vision and Needs

The Biomedical Research Integrated Domain Group (BRIDG) recently announced the release of version 2.1 of BRIDG. This version incorporates several new capabilities focused on representing the people, organizations, and core components describing clinical trials protocols. These changes include compatibility with the World Health Organization (WHO) and clintrials.gov clinical trials registries, and much better modeling of the protocol abstraction itself. Together these changes simplify the collection, analysis and comparison of standards-based clinical trials data between sites and between different trials.

BRIDG is a domain analysis model that facilitates semantic interoperability between standard data models and service data objects (SDO) like those developed by CDISC, HL7, and ISO. BRIDG has been developed collaboratively by a community that includes the Clinical Data Interchange Standards Consortium (CDISC), the HL7 Regulated Clinical Research Information Management Technical Committee (RCRIM TC), the US Food and Drug Administration (FDA), and the National Cancer Institute (NCI), specifically the caBIG® program.

Beginning with the release of BRIDG version 1.0 in June 2007, caBIG® contributed the data models for the Cancer Clinical Trials Object Model (CTOM) and the Patient Study Calendars (PSC). These first models were supplemented in BRIDG version 2.0 by information on adverse events (caAERS), the participant registry project, and models describing Persons/Organizations, part of the caBIG® COPPA project (Correlations, Organizations, Persons and Protocol Abstractions). More information about caBIG®'s involvement with BRIDG can be found here.

Current Solution

[Optional, briefly describe the existing solution and shortcomings.]

Proposed Solutions

Semantic Inheritance Concept Mapping: SIW Support for Complex DataTypes - Solution Chosen

This solution suggests to treat certain data types as associations, and certain data types as simple attributes.

The caDSR curation team will make a determination as to which data type will be treated as an association and which will be treated as an attribute.

A list of valid data types will be published so that model owners know which types they can use.

Functional Requirements

caDSR will only load ISO 21090 Data Types that are relevant to the COPPA Model and the BRIDG 2.1 Model. All other remaining data types will be loaded in caDSR at a later time.

Please see ISO 21090 Data Types spreadsheet (MasterListwithBRIDG.xls - no longer online)

GForge number
(hyperlinked)

Brief description of functional requirement
(enhancement or new feature)

Status
(Approved or Proposed)

Iteration

Non-Functional Requirements

This section describes in detail all the related requirements which must be met for this release but do not add functionality. These requirements are included in the scope and project plan due to level of effort or relative importance to the overall success of delivery of the release.

GForge number (hyperlinked)

Brief description of non-functional requirement

Status
(Approved or Proposed)

Iteration

Example, "Although there are no functional changes to the product for this requirement, the team must migrate the existing software to Hibernate 4.1 to be compatible with the caCORE technology stack."

General Support Activities

This section describes in detail all the related activities which must be performed for this release but do not add functionality. These activities are included in the scope and project plan due to level of effort or relative importance to the overall success of delivery of the release.

GForge number (hyperlinked)

Brief description of general support activity

Status
(Approved or Proposed)

Iteration

Example, "Level 2 Support, integration of help and training to the user community."

Stakeholder Summary

Customer Name

Role

Interest/Need

[Name]

[Title or role]

CBIIT Staff/Contractor Name

Role

Responsibilities

[Name]

[Role in this project]

Out of Scope Items

Items that are out of scope were evaluated as part of the initial scoping activities for this release, and subsequently not included in the final approved scope. These items are also documented in the cumulative backlog of requirements found on the product GForge site. They include out-of-scope functional requirements (enhancements or new features), bug fixes, non-functional requirements, and general support activities.

Open Questions and Gaps for ISO 21090 Data Types 2009

GForge number (hyperlinked)

Brief description of item moved from the in-scope section
with brief explanation added of why it was not included in this release

Iteration during which the item
was removed from in-scope

Document History

Document Version:

Click the Info tab. View the Recent Changes or click the link to view the page history.

Last Modified:

Refer to the first line displayed in the document window.

Project GForge site:

[Project GForge site link]

Most current version:

Unless the display includes a notice that you are viewing a previous version, you are viewing the most current version of this Scope Document for the release indicated in the title.

Revision history:

Click the Info tab. In the Recent Changes area, click the link to view the page history.

Review history:

Click the Info tab. In the Recent Changes area, note the developer who made each change and the date and time. Refer to the Key People Directory for their roles. Click the link to view any page or to view the page history, and then click the link for a page. When the page opens, view the comments and changes made in that version.

Related documents:

[Name and URL of each related document]

Project Information

CBIIT Management

Role

Responsibilities

[Name]

Product Manager

Oversees development of the product: features, functions, definition of stakeholders, priorities within the scope, timeframe for release

Avinash Shanbhag

Engineering Manager

Oversees NCICB caCORE software engineering practices, conducts design reviews, guides technical development

Denise Warzel

Product Line Manager

Oversees NCICB caCORE product line. Responsible for overall product integration, major and minor release cycles. Supports Product Manager.

  • No labels