**Cancer Central Clinical\
Participant Registry (C3PR)**

Software Requirements Specification

Version 2.0

Document Change Record

  ------------- -------------- -------------------------------------------
  Version       Date           Description
  Number                       

  1.0           11/12/2006     Patrick: Initial Draft

  1.1           12/1/2006      Patrick: Added some intro text

  1.2           12/12/2006     Ram: added content

  1.3           12/14/2006     Patrick: updated content

  1.4           12/17/2006     Ram: minor modifications

  1.5           12/18/2006     Patrick: accepted mods, delivered
  ------------- -------------- -------------------------------------------

TABLE OF CONTENTS

[1. Introduction 5](#introduction)

[1.1 Project Perspective 5](#project-perspective)

[1.1.1 Users and Characteristics 6](#users-and-characteristics)

[1.2 Release Overview 6](#release-overview)

[1.2.1 System scope 6](#system-scope)

[1.2.2 Out of scope for C3PR 2.0 7](#out-of-scope-for-c3pr-2.0)

[1.3 Document Overview 7](#document-overview)

[1.4 Document KEY 7](#document-key)

[1.5 Reference Documents 7](#reference-documents)

[1.6 Definitions 8](#definitions)

[2. SYSTEM requirements 9](#system-requirements)

[2.1 caBIG compatibility 9](#cabig-compatibility)

[2.1.1 Vocabularies and Data Elements
9](#vocabularies-and-data-elements)

[2.2 SYSTEM Environment 9](#system-environment)

[2.3 SECURITY Environment 9](#security-environment)

[3. C3PR requirements 11](#c3pr-requirements)

[3.1 FUNCTIONAL REQUIREMENTS 11](#functional-requirements)

[3.1.1 Manage Protocol 11](#manage-protocol)

[3.1.2 Manage Participant 11](#manage-participant)

[3.1.3 Register/Enroll Subject 12](#registerenroll-subject)

[3.1.4 Randomization 13](#randomization)

[3.1.5 Manage Eligibility Criteria 13](#manage-eligibility-criteria)

[3.1.6 Integration with other caBIG systems
13](#integration-with-other-cabig-systems)

[3.2 Non Functional requirements 14](#non-functional-requirements)

[3.2.1 General Requirements 14](#general-requirements)

[3.2.2 Security 15](#security)

[3.2.3 Auditing 15](#auditing)

[3.2.4 Logging 15](#logging)

[3.2.5 Exception handling 16](#exception-handling)

[3.2.6 Reliability 16](#reliability)

[3.2.7 Portability 16](#portability)

[3.2.8 Version control 16](#version-control)

[3.2.9 Software generation and integration
16](#software-generation-and-integration)

[3.3 Online User Documentation and Help System Requirements
16](#online-user-documentation-and-help-system-requirements)

[3.4 End User Account Management and Login
17](#end-user-account-management-and-login)

[4. Assumptions AND Dependencies 18](#assumptions-and-dependencies)

[4.1 Assumptions about system users 18](#assumptions-about-system-users)

[5. Usability 18](#usability)

[5.1 Design for ease of use 18](#design-for-ease-of-use)

[5.2 Sortable Columns 18](#supl21.3-sortable-columns)

[5.3 ACcessibility 18](#accessibility)

[6. General Assumptions 19](#general-assumptions)

[7. Dependencies 20](#dependencies)

[8. RISKS 21](#risks)

[APPENDIX A. ACRONYMS and abbreviations
22](#appendix-a.-acronyms-and-abbreviations)

# Introduction

This document captures the complete software requirements for the C3PR
V2 software as part of the caBIG™ project.

## Project Perspective

Researchers, who conduct clinical trials themselves and often require
comparative data for dosing, measurable clinical trial end-points, model
validation, encounter difficulty accessing aggregate clinical trials
data. This, in turn, limits their ability to advance the science. The
development and deployment of a central registry, containing requisite
information on clinical trials, will provide all groups (patients and
their families indirectly, community physicians and cancer researchers
directly) to meet their diverse set of informational and data needs.

C3PR Release 1 provides a highly configurable participant registry for
managing clinical study registration at a single site. However, it
cannot easily manage cross-site studies, and it can be very difficult to
install, configure, and manage. The primary goal of C3PR Release 2 is to
build upon Release 1 to make it more generally useful to the cancer
research community. A scoping goal will be for C3PR to manage
participant registration to multi-site studies. This involves the
integration of C3PR instances at different centers. Additionally,
integration beyond C3PR will be needed to perform institution-level and
PI-level eligibility checks. The current registration model is somewhat
limited, allowing for simplistic randomization based upon manual
assignment of participants to arms. Furthermore, protocol management in
C3PR will be greatly enhanced. Though C3PR is not intended as a central
protocol repository, protocol information is critical to the
registration process. Protocol information will be expanded to meet the
use cases of multiple eligibility check-points, multi-institutional
studies, and differing randomization schemes. C3PR Release 1 provided
registration from a participant-centric standpoint. This workflow will
be enhanced to provide registration from a protocol-centric view, and
reporting will be extended to provide this information to external
systems to generate complex reports.

### Users and Characteristics

> The likely users of C3PR are people with the job responsibilities
> listed below. The role(s) granted to each user in the application will
> depend on the specific responsibilities of the person's job and other
> institutional rules under which they execute their responsibilities.

-   Subject

-   Principle Investigator

-   Treating Physician

-   Data Manager

-   Protocol Manager

-   Registrar

-   IRB Manager

-   Site Manager

## Release Overview

### System scope 

The primary features that will be developed as part of the C3PR project
include the following:

-   **Protocol Management**: C3PR Release 2 will allow for the loading,
    management, and searching of protocols. Eligibility criteria and
    randomization will be accessible and managed through the web
    interface. C3PR does not aim to be the primary protocol management
    system; however, we envision C3PR to contain enough basic protocol
    information to register participants and track them on the protocol.

-   **Participant Management**: This component will manage all aspects
    of the participant data including address, contact information,
    searching, synchronization with external systems and relations
    management.

-   **Registration Management**: Complete registration management will
    be provided within the C3PR system including stratification,
    assignment to protocol arms with and without randomization.
    Registration status and notification will be a central goal of
    integration with external systems.

-   **Reports**: C3PR will allow for reports generation by providing
    data dumps to be incorporated with external data, as well as an
    internally managed reporting module to provided through the web
    interface.

-   **Eligibility Criteria Management**: C3PR will continue to support
    the optional import, review and approval process of the eligibility
    criteria. In Release 2 this support will include distinct
    eligibility checklists for different phases (or epochs) of the same
    protocol. The definition of all the eligibility checklists will
    optionally be maintained in the caDSR within the FormBuilder
    application and the C3PR system will provide support to import the
    eligibility checklist to be displayed dynamically within C3PR. Reuse
    of eligibility criteria through the caDSR will be explored.

-   **Auditing/Logging**: The Release 2 system aims to provide complete
    auditing features including tracking changes and record data as a
    snapshot prior to any data modifications.

-   **Login**: will component will leverage the current CSM based
    security model. Furthermore, the caGrid 1.0 security infrastructure
    will be leveraged for authentication, authorization, and trust
    fabrics.

-   **Data Loading**: Release 2 of the system will allow participant,
    registration, and protocol data to be loaded from external sources.
    The approach of the C3PR application is to provide data loading,
    API-based (web service), and web interface based methods to manage
    all aspects of the C3PR system.

-   **Clinical Data Access**: C3PR will continue to provide direct
    access to clinical data in C3D (and other clinical data management
    systems) for the selected participant on the selected protocol.

### Out of scope for C3PR 2.0

The following will be implemented in subsequent release(s):

-   None currently

## Document Overview

This SRS captures all the software requirements for the C3PR project.
The remaining SRS sections are organized as follows:

-   **Section 2, System Requirements Specification:** Describes the
    requirements specific to ensuring that C3PR conforms to the caBIG
    guidelines and requirements.

-   **Section 3, C3PR requirements**: Describes the functionality of
    C3PR

## Document KEY

The C3PR Release 2 project follows the iterative development of the
Unified Framework Process. Thus, each document is a snapshot of a
work-in-progress. The following conventions will be used throughout the
document:

-   [Red highlighting]{.mark} will indicate new items that need to be
    addressed immediately in the next iteration by the developers.

-   [Green highlighting]{.mark} will indicate new items that need to be
    addressed in the next iteration by the elaborators.

## Reference Documents

1.  C3PR Use Case Document

> https://GForge.nci.nih.gov/plugins/scmcvs/cvsweb.php/c3prv2/documentation/use_cases/c3prv2_use_cases.doc?cvsroot=c3prv2

2.  Risk Matrix

> https://GForge.nci.nih.gov/plugins/scmcvs/cvsweb.php/c3prv2/documentation/risks/?cvsroot=c3prv2

3.  Test approach

> http://GForge.nci.nih.gov/plugins/scmcvs/cvsweb.php/c3prv2/documentation/testing/c3prv2_test_plan.doc?cvsroot=c3prv2

## Definitions

**MUST** - This word means that the definition is an absolute
requirement of the specification.

**MUST NOT** - This phrase means that the definition is an absolute
prohibition of the specification.

**WILL** - This word means that the definition is an absolute future
requirement of the specification.

**WILL NOT** - This phrase mean that the definition is an absolute
future prohibition of the specification.

**SHOULD** - This word means that there may exist valid reasons in
particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed before choosing a
different course.

**SHOULD NOT** - This phrase means that there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or
even useful, but the full implications should be understood and the case
carefully weighed before implementing any behavior described with this
label.

**MAY** - This word means that a requirement is truly optional. The
developer may choose to include the item based on the needs of their
design.

# SYSTEM requirements

## caBIG compatibility

### Vocabularies and Data Elements

One of the main goals of caBIG is to ensure that all applications use
the same vocabulary and data elements for similar concepts across the
grid. This will eliminate any inconsistency in data descriptors
(metadata) and make it possible to pass semantically equivalent data
with confidence across various applications within the grid

  -----------------------------------------------------------------------
  **Req. ID** **Requirement**
  ----------- -----------------------------------------------------------
  VCDE-1      C3PR must use Enterprise Vocabulary Services (EVS) and
              Cancer Data Standards Repository (caDSR) for data elements
              and concepts that will be exposed through caBIG
              silver-compatible APIs, as well as the user interface.

  -----------------------------------------------------------------------

##  {#section .unnumbered}

## SYSTEM Environment

C3PR system will be developed on open source Java/J2EE platform using
JDK 1.5.

The caBIG compatibility guidelines do not address the issue of the
number of platforms and databases on which caBIG applications must run.
Because caBIG is an open source project, it is desirable that testing be
performed on the Linux platform.

+-----------+----------------------------------------------------------+
| **Req.    | **Requirement**                                          |
| ID**      |                                                          |
+===========+==========================================================+
| ENV-1     | The client software will be tested locally with the      |
|           | following operating systems:                             |
|           |                                                          |
|           | a.  Windows XP                                           |
|           |                                                          |
|           | b.  Linux                                                |
+-----------+----------------------------------------------------------+
| ENV-5     | The client software will be tested locally with the      |
|           | following browsers:                                      |
|           |                                                          |
|           | a.  Internet Explorer 5.0x, 6.0x                         |
|           |                                                          |
|           | b.  Mozilla Firefox                                      |
|           |                                                          |
|           | There will be no IE specific code used for C3PR. This    |
|           | includes technologies like DHTML and IE Specific         |
|           | JavaScripts.                                             |
+-----------+----------------------------------------------------------+
| ENV-10    | The application server will require at least the         |
|           | following:                                               |
|           |                                                          |
|           | a.  1 GHz CPU                                            |
|           |                                                          |
|           | b.  1 GB RAM                                             |
|           |                                                          |
|           | c.  2 GB hard disk                                       |
+-----------+----------------------------------------------------------+
| ENV-11    | The application server will require the following 3^rd^  |
|           | party software:                                          |
|           |                                                          |
|           | a.  Java 1.5.x                                           |
|           |                                                          |
|           | b.  Ant 1.6.x                                            |
|           |                                                          |
|           | c.  Oracle 9i or Oracle 10g                              |
|           |                                                          |
|           | d.  Apache Tomcat 5.1.28                                 |
|           |                                                          |
|           | e.  caGrid 1.0                                           |
+-----------+----------------------------------------------------------+
| ENV-15    | The client computer will require at least the following: |
|           |                                                          |
|           | a.  1 GHz CPU                                            |
|           |                                                          |
|           | b.  512 MB RAM                                           |
+-----------+----------------------------------------------------------+

## SECURITY Environment

  -----------------------------------------------------------------------
  **Req.     **Requirement**
  ID**       
  ---------- ------------------------------------------------------------
  SEC-5      C3PR will use CSM APIs for user authentication; that is, to
             verify a user's credentials and allow access to the
             application and authorization services.

  SEC-25     Each C3PR user must be authenticated against a specific
             trusted Identity Provider (IdP) registered with Dorian in
             the caGrid in order to execute the Federated Query. The C3PR
             GUI should provide a means for users to login.

  SEC-30     In Phase one of the C3PR project, the login will be based on
             two fields; username and password.

  SEC-35     The login infrastructure may provide "Remember Me" feature
             in which the username and password are stored on the user's
             client machine.

             
  -----------------------------------------------------------------------

.

# C3PR requirements

## FUNCTIONAL REQUIREMENTS

### Manage Protocol

  -----------------------------------------------------------------------
  **Req.     **Requirement**
  ID**       
  ---------- ------------------------------------------------------------
  FR-1       The system must allow manual creation of a basic Protocol
             definition through the web interface.

  FR-5       The system must support loading of a Protocol definition
             from a structured text file.

  FR-6       The system may support the exporting of a Protocol
             definition into a structured text file.

  FR-10      The system must expose a programmatic interface for creation
             of a Protocol definition.

  Fr-15      The system must provide functionality that enables
             propagation of a new Protocol definition to other systems.
             Minimally this includes another instance of C3PR.

  FR-20      The system must support optional verification/QC for the new
             Protocol definition.

  FR-25      The system must provide functionality to search for a
             Protocol based on data elements that make up the Protocol
             object. The specific data elements are still being
             enumerated.

  FR-30      The system must allow updating a Protocol definition.

             When a protocol definition is updated, notification must be
             made concerning patients that registered on the modified
             portion of the protocol.

  FR-35      The system must allow adding and removing information about
             the various sites where the Protocol is being implemented.

  FR-40      The system must allow managing basic trial design aspects of
             a Protocol. This includes ability to manage Epochs, Arms,
             and Stratification.

  FR-45      The system must provide functionality to enable tracking of
             Protocol history, which includes who modified the protocol
             and when it was modified. Entire versions of the protocol
             will not be tracked (i.e. full provenance is not tracked).

  FR-50      The system must allow maintaining Protocol status
             information. It must provide programmatic interfaces for
             updating the status of a Protocol.

  FR-55      The system must provide functionality to enable storing
             multiple identifiers for a Protocol. It must also support
             site/institution specific identifiers.

  FR-60      The system must allow capturing the eligibility criteria for
             each Epoch in the Protocol

  FR-61      The system must provide functionality to enable capturing of
             Protocol amendments.

  FR-62      The system must provide functionality to enable capturing of
             diseases of a Protocol.
  -----------------------------------------------------------------------

### Manage Participant

Note: FR-65 and FR-66 delineate between the two types of participants:
Subject and Study Personnel. Where not otherwise noted, the rest of the
use cases refer to both types of participants.

  -----------------------------------------------------------------------
  **Req.     **Requirement**
  ID**       
  ---------- ------------------------------------------------------------
  FR-65      The system must allow manual creation of a basic Study
             Personnel definition.

  FR-66      The system must allow manual creation of a basic Subject
             definition.

  FR-70      The system must support loading of a Participant definition
             from a structured text file .

  FR-71      The system may support the exporting of a Participant
             definition to a text file.

  FR-75      The system must expose a programmatic interface for creation
             of a Participant definition.

  Fr-80      The system must provide functionality that enables
             propagation of a new Participant definition to other
             systems. Minimally, this includes other instances of C3PR.

  FR-85      The system may support optional verification/QC for a new
             Participant definition created programmatically through an
             API (loaded from a file or via propagation).

  FR-90      The system must provide functionality to search for a
             Participant based on the data elements that make up the
             Protocol object.

  FR-95      The system must allow updating information pertaining to a
             Participant.

  FR-100     The system must allow maintaining contact information of a
             Participant.

  FR-105     The system must allow maintaining address information of a
             Participant.

  FR-110     The system must allow maintaining multiple identifiers for a
             Participant.

  FR-115     The system must allow maintaining multiple roles for a
             Participant on any given protocol.

             

             

             

             

             
  -----------------------------------------------------------------------

### Register/Enroll Subject

  -----------------------------------------------------------------------
  **Req.     **Requirement**
  ID**       
  ---------- ------------------------------------------------------------
  FR-110     The system must allow enrollment/registration of a Subject
             to an Arm of a Protocol.

  FR-115     The system must provide functionality to enable viewing of
             registration history of a Subject.

  FR-120     The system must allow propagation of registration
             information from C3PR to other CTMS systems. Minimally this
             must include other instances of C3PR, but may also include
             other systems such as Study Calendar and caAERS.

  Fr-125     The system may allow storing of screening data of a Subject
             on a Protocol.

  FR-130     The system must allow closing the registration of Subjects
             on a Protocol.

  FR-135     The system must allow registration of Subjects that do not
             count towards the total accrual for a Protocol.

  FR-140     The system may support reservation of a registration on a
             Protocol for a Subject.

  FR-145     The system may allow automatic registration to all the
             correlative studies that exist for a Protocol.

  FR-150     The system must provide functionality to override the
             eligibility criteria and allow registration of a Subject
             even if all the eligibility criteria are not met.

  FR-155     The system must track accrual

  FR-160     The system must provide for accrual ceilings

  FR-165     The system must provide notification when accrual limits
             have been met

             

             

             

             
  -----------------------------------------------------------------------

### Randomization

  -----------------------------------------------------------------------
  **Req.     **Requirement**
  ID**       
  ---------- ------------------------------------------------------------
  FR-160     The system must support randomization done externally (e.g.
             via email)

  FR-165     The system should provide functionality for capturing the
             book that could be used for performing the randomization.

  FR-170     The system should support programmatic randomization by
             interfacing with the randomization hub that is currently
             being developed.

  FR-175     The system may allow storing of screening data of a
             Participant on a Protocol.

             

             

             

             

             
  -----------------------------------------------------------------------

### Manage Eligibility Criteria

  -----------------------------------------------------------------------
  **Req.     **Requirement**
  ID**       
  ---------- ------------------------------------------------------------
  FR-180     The system must provide for management of eligibility
             criteria through the web interface.

  FR-181     The system must provide for yes/no questions in eligibility
             criteria checks.

  FR-185     The system must provide for yes/no flag for an eligibility
             criteria check.

  FR-190     The system must support eligibility criteria loading from
             the caDSR

  FR-195     The system should support eligibility criteria loading from
             a file

  FR-200     The system may support eligibility criteria exporting to a
             file

             

             

             

             

             

             

             
  -----------------------------------------------------------------------

### Integration with other caBIG systems

  -----------------------------------------------------------------------
  **Req.     **Requirement**
  ID**       
  ---------- ------------------------------------------------------------
  FR-200     The system must provide integration with the C3D for
             reserving a patient position on a protocol.

  FR-201     The system must send a registration message, to be received
             by C3D, and then get the patient position back.

  FR-205     The system must integrate with the Patient Study Calendar
             (PSC).

  FR-206     The system must send a registration message to be received
             by PSC.

  FR-210     The system must integrate with the Cancer Adverse Event
             Reporting System (caAERS).

  FR-211     The system must send a registration message to be received
             by caAERS.

  FR-215     The system may integrate with Protocol Lifecycle Tracking
             (PLT) system for receiving Protocol Lifecycle events.

  FR-220     The system must provide integration points to facilitate
             integration with legacy systems existing at the adopter
             institutions.

  FR-225     The system may integrate with caMatch.

  FR-230     The system must integrate with the Cancer Data Standards
             Repository (caDSR) and Enterprise Vocabulary Services (EVS)
             (e.g. for eligibility criteria)

  FR-235     The system must integration with the CTOM LabViewer.

  FR-236     The system must send a registration message to be received
             by CTOM LabViewer.

             

             
  -----------------------------------------------------------------------

##  {#section-1 .unnumbered}

## Non Functional requirements

### General Requirements

+---------+------------------------------------------------------------+
| **Req.  | **Requirement**                                            |
| ID**    |                                                            |
+=========+============================================================+
| GEN-5   | The use cases for the C3PR V2 system call for              |
|         | grid-enablement. Therefore, the C3PR V2 system will be     |
|         | deployable as a service on the caGrid. This would entail   |
|         | developing an analytical service and deploying it on       |
|         | caGrid.                                                    |
+---------+------------------------------------------------------------+
| GEN-15  | The C3PR V2 web interface should be driven by metadata     |
|         | registered in the caDSR.                                   |
+---------+------------------------------------------------------------+
| GEN-20  | The C3PR V2 system should be able to interact with other   |
|         | grid services deployed on caGrid 1.0.                      |
+---------+------------------------------------------------------------+
| GEN-25  | An intuitive user friendly graphical user interface must   |
|         | be developed.                                              |
+---------+------------------------------------------------------------+
| GEN-30  | Performance is a major consideration for any enterprise    |
|         | system like C3PR. Web page requests must resolve in a      |
|         | timely manner, which essentially is on the order of few    |
|         | seconds.                                                   |
+---------+------------------------------------------------------------+
| GEN-40  | The application will address section 508 of the            |
|         | Rehabilitation Act of 1973 where appropriate and           |
|         | reasonable.                                                |
+---------+------------------------------------------------------------+
| GEN-50  | The application will address Title 21 Code of Federal      |
|         | Regulations (21 CFR Part 11) Electronic Records where      |
|         | appropriate and reasonable.                                |
+---------+------------------------------------------------------------+
| GEN-51  | The system must be adequately validated during the system  |
|         | development                                                |
|         |                                                            |
|         | lifecycle                                                  |
+---------+------------------------------------------------------------+
| GEN-52  | The system must provide the functionality to generate and  |
|         | manage accurate                                            |
|         |                                                            |
|         | data records during the development processes.             |
+---------+------------------------------------------------------------+
| GEN-53  | The security of data records must be adequately protected  |
|         | to retain                                                  |
|         |                                                            |
|         | confidentiality, integrity and availability.               |
+---------+------------------------------------------------------------+
| GEN-54  | The system must limit access to authorized individuals.    |
+---------+------------------------------------------------------------+
| GEN-55  | The system must comply with the caBIG™ Common Security     |
|         | Model.                                                     |
+---------+------------------------------------------------------------+
| GEN-56  | The system must be auditable.                              |
+---------+------------------------------------------------------------+
| GEN-59  | Electronic Signatures should meet necessary requirements   |
|         | as described in 21                                         |
|         |                                                            |
|         | CFR part 11.                                               |
+---------+------------------------------------------------------------+
| GEN-60  | The system development lifecycle must include validity     |
|         | checks for all data                                        |
|         |                                                            |
|         | fields.                                                    |
+---------+------------------------------------------------------------+
| GEN-61  | System documentation should be maintained in a controlled  |
|         | environment.                                               |
+---------+------------------------------------------------------------+
| GEN-62  | System developers must adhere to the caBIG™ Data Sharing & |
|         | Intellectual                                               |
|         |                                                            |
|         | Capital Policy and Procedures.                             |
+---------+------------------------------------------------------------+
| GEN-70  | The system must be caBIG silver-level compatible.          |
+---------+------------------------------------------------------------+

### Security

The following table contains the different kinds of user groups:

+----------+-----------------------------------------------------------+
| **System | -   Is a \"super-user\" who manages the application       |
| Adminis  |                                                           |
| trator** | -   Approves and manages user registration process        |
|          |                                                           |
|          | -   Grants users to a role within the application         |
+----------+-----------------------------------------------------------+
| **Study  | -   Reviews completed Study definitions to determine if   |
| Adminis  |     they are complete and correct                         |
| trator** |                                                           |
|          | -   Determines which studies will be editable/viewable    |
|          |     for each Clinical Research Coordinator and viewable   |
|          |     for each Research Associate                           |
+----------+-----------------------------------------------------------+
| **Study  | -   Creates new Study definitions in the system           |
| Coord    |                                                           |
| inator** |                                                           |
+----------+-----------------------------------------------------------+
| **Reg    | -   Enrolls Participants to Studies for which approval    |
| istrar** |     has been granted                                      |
+----------+-----------------------------------------------------------+

The following is a list of security requirements:

  ---------- ------------------------------------------------------------
  **Req.     **Requirement**
  ID**       

  NFR -- 5   System Administrator will assign user to role (see table
             above) using UPT

  NFR -- 10  Role-based security must be enforced throughout the SCM
  ---------- ------------------------------------------------------------

### Auditing

The system must audit each and every user action that results in
database access (read or write). Examples include: add/edit study or
participant data, user login, query etc

The audit information must contain the following information:

1.  User who performed the action

```{=html}
<!-- -->
```
1.  IP address of the computer from which the action is performed

2.  Timestamp of action

3.  Object and data element (i.e. table name and column name)

4.  Previous value and current value of the data element

  ---------- ------------------------------------------------------------
  **Req.     **Requirement**
  ID**       

  AUD - 5    C3PR will capture required audit information (see list
             above)
  ---------- ------------------------------------------------------------

### Logging

Logging must be implemented in all the architectural layers --
presentation, business logic and data access layers -- of the C3PR
system. Log4J, which is a well known open source logging framework will
be used for implementing the logging functionality. In the case of the
C3PR middle tier, logs will be written to a file that will be stored on
the application server's file system. The log file for the database will
be stored on the database server. This will greatly facilitate
de-bugging problems that arise during the use of the C3PR system.

### Exception handling

Any runtime exceptions or errors must be reported to the user in a
graphical window containing the probable cause of the problem and how to
rectify that.

The exceptions and errors shall be divided into two groups:

-   User errors

-   OS and System/Application errors.

### Reliability

The developers will do their best, within the time-limits imposed on
them, to deliver a perfectly working product. No actual guarantees to
the amount of software faults (bugs) in the finished product will be
made, other than the fact that the product must pass a previously
created set of tests. The details of this test bench are beyond the
scope of this document, and will be specified in a separate document
(see the test approach:
http://gforge.nci.nih.gov/plugins/scmcvs/cvsweb.php/c3prv2/documentation/testing/c3prv2_test_plan.doc?cvsroot=c3prv2).

### Portability

Since Java is platform-independent, the only portability requirement is
to stay well clear of using native libraries and platform dependent
3^rd^ party tools and java libraries.

All the paths for the local file system must not be hard coded. Example
C:\\myDir etc.

### Version control

The source code generated will be kept in CVS on GForge site.

### Software generation and integration

All code produced must be commented and documented. The process for
building the finished product and all its sub-components from source
code must be documented.

## Online User Documentation and Help System Requirements

  -----------------------------------------------------------------------
  **Req.     **Requirement**
  ID**       
  ---------- ------------------------------------------------------------
  HLP-10     Help includes URLs pointing to external web sites, and the
             system will launch the browser with the target URL.

  HLP-15     There shall be a variety of help levels and documentation
             formats accessible from the UI. Ex. user cookbooks with
             examples, FAQ, email contacts etc.

  HLP-20     The Help System may allow user to store his/her own FAQ into
             the Help System for later use.

  HLP-30     The user may be able to print the Help documentation from
             the UI directly.

  HLP-35     Help may be context-sensitive (relevance based view of the
             contents) where relevant. In the web interface, mouse-over
             banners will indicate use of buttons and fields.

  HLP-40     The help infrastructure may allow user to search within the
             help content based on keywords.
  -----------------------------------------------------------------------

## End User Account Management and Login

A potential user who wants to have access to the C3PR system must have a
valid username/password combination and appropriate access privileges.
C3PR users will be provisioned using the User Provisioning Tool (UPT)
provided by the CSM.

+---------+------------------------------------------------------------+
| **Req.  | **Requirement**                                            |
| ID**    |                                                            |
+=========+============================================================+
| UACCT-1 | The system must allow anyone who can navigate to the C3PR  |
|         | URL and has a valid account with appropriate access        |
|         | privileges and using the browser listed in requirement     |
|         | ENV_5 to have access to the system.                        |
+---------+------------------------------------------------------------+
| UACCT-5 | The system must provide a mechanism to specify a           |
|         | designated email for the system administrator.             |
+---------+------------------------------------------------------------+
| U       | The application's help page must provide access to the     |
| ACCT-10 | following information:                                     |
|         |                                                            |
|         | a.  Name of the System Administrator                       |
|         |                                                            |
|         | b.  Email address of the System Administrator              |
|         |                                                            |
|         | c.  Phone or pager number of the System Administrator      |
|         |                                                            |
|         | d.  Instructions for contacting Application Support        |
|         |                                                            |
|         | e.  Log in functionality                                   |
+---------+------------------------------------------------------------+
| U       | The system must allow a user to log out of the             |
| ACCT-15 | application.                                               |
+---------+------------------------------------------------------------+
| U       | If a user forgets his or her password, he or she will be   |
| ACCT-20 | able to contact the System Administrator to reset the      |
|         | password.                                                  |
+---------+------------------------------------------------------------+

##  {#section-2 .unnumbered}

# Assumptions AND Dependencies

## Assumptions about system users

AS-USER-1: All users are familiar with the basic conventions of web user
interfaces. If they are not familiar with these conventions, they will
be trained independently of the C3PR project.

AS-USER-5: All users are familiar with medical terminology to the extent
required to do their jobs. The definitions provided as system metadata
are not intended to provide comprehensive understanding of the concepts
in the domain, but rather to unambiguously identify them to a
knowledgeable user.

# Usability 

##  Design for ease of use 

> The user interface shall be designed for ease-of-use by the designated
> end-users, shall use terms common to the user's normal business
> environment, and shall require little to no additional training on the
> system.

## SUPL21.3 Sortable Columns 

> The results from the query execution will be shown in a tabular
> fashion and the user will be able to sort based on any column\'s data.

## ACcessibility

> The C3PR user interface should be accessible via a web browser.

# General Assumptions

Following is a list of assumptions

-   The user is connected to the Internet continuously during a session.

```{=html}
<!-- -->
```
-   The caBIG and other systems (services) used in the C3PR project are
    up and running so that the application can communicate with them

-   C3PR doesn't support any service level auditing; it is assumed that
    the auditing is taken care at the individual service level.

-   Every C3PR user has username and password stored in an identity
    provider.

# Dependencies

  -----------------------------------------------------------------------
  **Dep.     **Dependency Description**
  ID**       
  ---------- ------------------------------------------------------------
  DEP-5      Since C3PR system will be based on the infrastructure
             provided caGrid 1.0, there is a very strong dependency on
             it. We anticipate working very closely with the caGrid 1.0
             development team. We will be using the interim stable builds
             of caGrid 1.0 during our development cycle.

             

             
  -----------------------------------------------------------------------

# RISKS

All recognized risks for C3PR development project are listed in the
document C3PR Risk Matrix (listed in the *Reference Documents* section).
To facilitate maintenance of the risk matrix, we do not reproduce it
here.

# APPENDIX A. ACRONYMS and abbreviations {#appendix-a.-acronyms-and-abbreviations .unnumbered}

  --------------- -------------------------------------------------------
  **Acronym**     **Stands for**

  API             Application Programming Interface

  caBIG           Cancer Biomedical Informatics Grid

  caDSR           Cancer Data Standards Repository

  C3PR            Cancer Central Clinical Participant

  CAP             College of American Pathologists

  CDE             Common Data Element

  EVS             Enterprise Vocabulary System

  HIPAA           Health Insurance Portability and Accountability Act

  NCI             National Cancer Institute

  SOW             Statement of Work

  UML             Unified Modeling Language

  V/CDE           Vocabulary and Common Data Elements (Workspace)

                  
  --------------- -------------------------------------------------------