From CTMS_WIKI
Introduction
Background
The caBIG Clinical Trials Suite (CCTS) is an enterprise clinical trials system being designed primarily for use in trial sites. The suite is comprised of a collection of interoperable modules covering a broad range of key areas in cancer clinical trials management. These include patient registration via C3PR, patient scheduling via PSC, adverse events reporting via caAERS, lab analysis via LabViewer, and clinical data management via C3D. Integration between these applications is centered around five key scenarios: Study Creation, Register Subject, Load Labs in CDMS, Lab-driven AE Creation, and AE-Triggered Schedule Change. The implementation is based upon the caGrid infrastructure with caXchange as the Enterprise Service Bus for reliable message routing and GAARDS providing robust security.
Scope
This document captures the requirements for all CCTS-related products. The goal of this is to provide a global view of the requirements to better understand how they overlap, how they conflict, and gaps in the overall requirements.
This document is a work in progress used strictly for planning for the CCTS 2.0 release. Up until that release, it could be altered in any way.
Related Documentation
CCTS
| Req. ID | Requirement Description
|
| DEPLOYMENT
|
| CCTS-SECURITY-001 | The security infrastructure must meet both intra- and inter-institutional requirements, e.g. it must provide for identity management within and across institutions, it must provide for trust within and across institutions, etc.
|
| CCTS-SECURITY-002 | The security infrastructure should provide minimal footprint, especially when deployed in a single institution setting
|
| CCTS-SECURITY-003 | The security infrastructure must not be bound to a specific CCTS product deployment architecture (e.g. the security infrastructure must support cases where CCTS products are deployed in the same container, same machine, different containers, different machines, etc.)
|
| DATA PRIVACY
|
| CCTS-SECURITY-101 | The security infrastructure must provide for data privacy between applications (e.g. data encryption) (i.e. a third party must not be able to view the details of data being exchange should they gain access to the communication channel)
|
| CCTS-SECURITY-102 | The security infrastructure must provide a mechanism to tie a user identity to data the user wishes to exchange via service invocation
|
| USER IDENTITIES
|
| CCTS-SECURITY-201 | The security infrastructure must provide for a mechanism to uniquely identify users
|
| CCTS-SECURITY-202 | The security infrastructure should provide for a mechanism to uniquely identify hosts where needed
|
| CCTS-SECURITY-203 | The security infrastructure must support central administrations of users - a user should only need to be provisioned once for all services and applications participating in CCTS
|
| CCTS-SECURITY-204 | Users from different organizations should be able to be identified from each other when used
|
| ROLES AND AUTHORIZATION
|
| CCTS-SECURITY-401 | The security infrastructure must support central administration of roles - a user should only need to provision roles once for all services and applications participating in CCTS
|
| CCTS-SECURITY-402 | The security infrastructure must support roles based upon site (structural roles) and study (functional roles)
|
| CCTS-SECURITY-403 | The security infrastructure should allow applications to maintain their own independent set of privileges and make authorization decisions based upon them
|
| DELEGATION
|
| CCTS-SECURITY-501 | The security infrastructure should provide for delegation of user identities such that the user can allow a third party to tie his identity to data exchanged upon their request (e.g. a user should be able to delegate their credentials to the middle tier) - this is required for federated authorization, third party authorization, and auditing/logging
|
| SSO
|
| CCTS-SECURITY-601 | A user must not be required to log into another application once they have already logged into one application (i.e. the infrastructure must support single sign-on)
|
| CCTS-SECURITY-602 | A user should not be able to access an application participating in single sign-on once they have logged out of one application or have been logged out of the single sign-on session (i.e. the infrastructure should support single sign-off)
|
| EXTERNAL SYSTEMS
|
| Req. ID | Requirement Description
|
| CCTS-BRIDG-001 | All domain data exchanged in CCTS must be represented by a domain model
|
| CCTS-BRIDG-002 | All domain models in CCTS must be harmonized at the analysis level with BRIDG 2.1
|
| CCTS-BRIDG-003 | Wherever applicable, ISO datatypes found in the BRIDG 2.1 model must be leveraged
|
| CCTS-BRIDG-101 | All domain models must be registered in the caDSR with corresponding concepts mapped in the EVS
|
| CCTS-BRIDG-102 | CDEs registered in the caDSR must map to BRIDG 2.1 registered CDEs wherever applicable
|
| CCTS-BRIDG-103 | Concept mappings in the EVS must map to BRIDG 2.1 concept mappings wherever applicable
|
| Req. ID | Requirement Description
|
| CCTS-PORTAL-001 | The portal must provide a unified user interface to access all of the CCTS web-based applications
|
| CCTS-PORTAL-002 | The Portal should not restrict look-and-feel of each CCTS application
|
| CCTS-PORTAL-003 | The Portal should not restrict which application container individual applications are deployed
|
| CCTS-PORTAL-004 | The portal must not inhibit the current or planned functionality of the CCTS applications
|
| CCTS-PORTAL-005 | The portal must not restrict CCTS messaging
|
| CCTS-PORTAL-006 | The portal must allow the user to "hot-link" between the applications
|
| CCTS-PORTAL-007 | The portal must allow the user to navigate between the applications using a higher-level (portal-level) navigation system (e.g. tabs or menus)
|
| CCTS-PORTAL-008 | The portal should maintain all views (CCTS application and otherwise) within a single browser window and a single browser tab
|
| CCTS-PORTAL-101 | The portal must allow portlet integration
|
| CCTS-PORTAL-102 | The portal must support JSR 168
|
| CCTS-PORTAL-103 | The portal should support JSR 286
|
| CCTS-PORTAL-201 | The portal must provide a front-page dashboard
|
| CCTS-PORTAL-202 | The dashboard should act as a springboard to the CCTS applications (e.g. the portal should provide context-sensitive hot-linking into CCTS applications)
|
| CCTS-PORTAL-203 | The dashboard should provide a reporting-oriented view across the CCTS applications (e.g. through data reports and/or graphs)
|
| CCTS-PORTAL-204 | The dashboard should display specific views based upon the user's role
|
| CCTS-PORTAL-301 | The portal must allow the user to login through the CCTS single sign-on (SSO) mechanisms
|
| Req. ID | Requirement Description
|
| CCTS-SMOKE-001 | The smoke tests must validate the correct deployment of the web applications
|
| CCTS-SMOKE-002 | The smoke tests must validate the correct deployment of the domain grid services
|
| CCTS-SMOKE-003 | The smoke tests must validate the message-based integration of the applications
|
| CCTS-SMOKE-004 | The smoke tests must validate that the grid security infrastructure is deployed correctly
|
| CCTS-SMOKE-005 | The smoke tests must validate that WebSSO is deployed correctly
|
| CCTS-SMOKE-101 | The smoke tests should provide useful error messages
|
| CCTS-SMOKE-102 | The smoke tests should test all of the functionality they are designed to test without stopping should a failure be encountered
|
| CCTS-SMOKE-103 | The smoke tests should be automated wherever possible
|
| CCTS-SMOKE-104 | The smoke tests should allow the applications to be returned to their original base installed datasets
|
| Req. ID | Requirement Description
|
| CCTS-HOTLINK-001 | Applications must be able to link between each other (known as hot-links)
|
| CCTS-HOTLINK-002 | Hot-links must be able to maintain context between applications, e.g. hot-linking from a subject in one application should bring the user to the same subject in the other application
|
| CCTS-HOTLINK-003 | Hot-links should be plain HTML links
|
| CCTS-HOTLINK-004 | Hot-links should be maintained across versions of an application
|
| CCTS-HOTLINK-101 | It must be possible to customize whether a hot-link replaces the current window or opens a new window
|
| CCTS-HOTLINK-102 | When hot-links open a new window, it must be possible to customize the hot-link such that hot-links to one application always open in that window
|
| CCTS-HOTLINK-103 | When hot-links open a new window, the new window should gain focus in the browser
|
| Req. ID | Requirement Description
|
| CCTS-GRIDDEPLOY-001 | Application grid service deployment must be relatively simple, such as running a handful of commands
|
| CCTS-GRIDDEPLOY-002 | Application grid services should have their configuration properties externalized for easy configuring and upgrading
|
| CCTS-GRIDDEPLOY-003 | Configuration files should be colocated with existing application configuration files
|
| CCTS-GRIDDEPLOY-004 | Configuration files should leverage common property names with existing configuration files
|
| Req. ID | Requirement Description
|
| CCTS-MSGID-001 | Each message must provide key identifiers for cross-linking data
|
| CCTS-MSGID-002 | The key identifiers should be a minimal, common set across messages
|
| Req. ID | Requirement Description
|
| CCTS-PKG-001 | CCTS should be bundled into a single compressed file
|
| CCTS-PKG-002 | Application teams must tag or branch before cutting CCTS releases or release candidates
|
| CCTS-PKG-003 | The bundle must include each application and related documentation
|
| CCTS-PKG-004 | The bundle should include the appropriate caGrid components
|
| CCTS-PKG-005 | The bundle must include CCTS specific documentation
|
| Req. ID | Requirement Description
|
| CCTS-ESB-001 | Messages exchanged between CCTS components must be delivered reliably
|
| CCTS-ESB-002 | Messages must be exchanged asynchronously
|
| CCTS-ESB-101 | Middleware must integrate with the CCTS technology stack
|
| CCTS-ESB-102 | Messages must be exchanged via grid services
|
| CCTS-ESB-103 | Messages must be exchanged securily
|
| CCTS-ESB-104 | Messages must be exchanged as the user the originated them
|
| CCTS-ESB-201 | Messages that involve multiple recipients must be exchanged in transactions
|
| CCTS-ESB-202 | Transactional messages must support rollback
|
| Req. ID | Requirement Description
|
| CCTS-DEPLOY-001 | Wherever possible, virtual machines should be allowed in place of hardware
|
| CCTS-DEPLOY-002 | In the interest of a separation of concerns, separate machines should be allocated for grid, database, and applications
|
| CCTS-DEPLOY-003 | The deployment should utilize a minimum number of machines and containers while still meeting other requirements
|
| CCTS-DEPLOY-004 | Each grid component (Dorian, GTS, CDS, etc.) should be deployed as a separate user
|
| CCTS-DEPLOY-005 | Dorian may be deployed on real hardware, not on a virtual machine
|
| CCTS-DEPLOY-006 | Applications must be deployable to the same container
|
| CCTS-DEPLOY-007 | Applications should be deployed to the same container
|
| CCTS-DEPLOY-008 | caXchange should be deployed to a different container than the applications
|
| Req. ID | Requirement Description
|
| CCTS-MSG-001 | Messages must leverage semantics for defining meaning of data elements
|
| CCTS-MSG-002 | Message semantics must be derived from BRIDG wherever possible
|
| CCTS-MSG-101 | Messages must leverage a formal syntax that describes/constrains the structure of the message
|
| CCTS-MSG-102 | Messages should be passed as XML
|
| CCTS-MSG-103 | XML-based messages must leverage XML Schema to define their structure
|
| CCTS-MSG-201 | A minimal set of common identifiers should be leveraged to link data items (such as Studies) across applications
|
| CCTS-MSG-301 | Message semantics should be registered in the caDSR
|
| CCTS-MSG-302 | Message syntactics should be registered in the GME
|
| Req. ID | Requirement Description
|
| CCTS-DISCOVERY-001 | Services must be able to be advertised to an IndexService
|
| CCTS-DISCOVERY-002 | Service-level metadata should include all standard caGrid service-level metadata
|
| CCTS-DISCOVERY-003 | Service-level metadata should include the semantics (e.g. metadata registered in the caDSR)
|
| Req. ID | Requirement Description
|
| CCTS-CI-001 | A CI environment must be leveraged that provides automation
|
| CCTS-CI-002 | A single CI environment should be provided to perform automation on all CCTS projects
|
| CCTS-CI-003 | CI must automate on a continuous basis or whenever code is checked into a repository
|
| CCTS-CI-004 | CI should be setup to automate on regular intervals, such as nightly or weekly
|
| CCTS-CI-005 | CI must provide immediate feedback to users subscribed to particular events (e.g. when a build breaks)
|
| CCTS-CI-006 | CI must provide feedback when an automated task is fixed (e.g. once a project builds successfully after breaking)
|
| CCTS-CI-007 | CI should provide a publicly viewable dashboard
|
| CCTS-CI-008 | CI should maintain a history of its automations
|
| CCTS-CI-009 | CI should maintain a history of generated artifacts
|
| CCTS-CI-201 | CI must automate code checkout and building
|
| CCTS-CI-202 | CI must automate unit testing
|
| CCTS-CI-203 | CI must automate integration testing
|
| CCTS-CI-204 | CI must automate deployments
|
| CCTS-CI-205 | CI should automate system tests
|
| CCTS-CI-206 | CI must automate technology stack testing (e.g. different database platforms)
|
| CCTS-CI-207 | CI may automate stress testing
|
| CCTS-CI-208 | CI may automate release generation
|
| CCTS-CI-209 | CI must automate report generation (e.g. code coverage reports)
|
| Req. ID | Requirement Description
|
| CCTS-URP-001 | A web application should be used to provision users (referred to hereafter as the user provisioning application)
|
| CCTS-URP-002 | A web application should be used to provision roles (referred to hereafter as the role provisioning application)
|
| CCTS-URP-003 | The user provisioning application and role provisioning application should be the same application
|
| CCTS-URP-004 | Web applications should be able to be plugged into the CCTS portal
|
| CCTS-URP-101 | The user provisioning application must support creating new users by assigning a user name and password
|
| CCTS-URP-102 | The user provisioning application must support removing or deactivating users
|
| CCTS-URP-103 | The user provisioning application must support the CCTS component for user management (i.e. CSM)
|
| CCTS-URP-104 | The user provisioning application should support assignment of a grid identity
|
| CCTS-URP-105 | The user provisioning application should allow for individual users to change their password
|
| CCTS-URP-106 | The user provisioning application should leverage the CCTS authorization module to determine the users that can manage users
|
| CCTS-URP-201 | The role provisioning application must allow roles to be assigned to existing users
|
| CCTS-URP-202 | The role provisioning application must allow roles to be removed or deassigned from users
|
| CCTS-URP-203 | The role provisioning application must allow a variety of privileges to be assigned or de-assigned to roles
|
| CCTS-URP-204 | The role provisioning application must allow users to have privileges on specific entities (e.g: referred to protection elements in CSM).
|
| CCTS-URP-205 | The specific entities mentioned in CCTS-URP-204 cross across applications and hence need not be linked to individual applications.
|
| CCTS-URP-206 | The application should allow the creation of users without any roles/privileges being assigned to them.
|
| CCTS-URP-207 | The role provisioning application must support the CCTS component for role management (i.e. GridGrouper)
|
| CCTS-URP-208 | The role provisioning application should leverage the CCTS authorization module to determine the users that can manage roles
|
| CCTS-URP-209 | The role provisioning application should allow the provisioning of multiple roles for a user at a single time (e.g. through a set of checkboxes)
|
| CCTS-URP-210 | The role provisioning application must support the hierarchicaly structure of CCTS roles, which includes system-level roles, site-level roles, and study-level roles
|
| CCTS-URP-211 | The role provisioning application should insulate the user as much as possible from the hierarchicaly nature of the roles (e.g. the user should be able to provision all site-level roles for a single user without having to navigate between groups)
|
| CCTS-URP-212 | The role provisioning application should allow the user to have different privileges based on the application being accessed. (e.g. the user should be able to have different privileges for different application all the while having the same centralized role)
|
| Req. ID | Requirement Description
|
| CCTS-CDH-001 | CCTS applications should provide the ability to hot-link to Tissue Banking and Pathology Tools (specifically, caTissue suite)
|
| CCTS-CDH-101 | CCTS applications should provide the ability to hot-link to Imaging tools (specifically, NCIA)
|
| CCTS-CDH-201 | CCTS applications should provide the ability to hot-link to basic science tools (specifically, caArray)
|
| CCTS-CDH-501 | Cross-domain hot-links must be contextual (i.e. they must be "deep links" that bring you to a portion of the target application that relates to data in the source application)
|
| CCTS-CDH-502 | Cross-domain hot-links should bring you directly to the deepest location appropriate (e.g. data for a specific subject on a trial)
|
| CCTS-CDH-503 | Cross-domain hot-links may leverage search capabilities present in the target application to pre-fill search fields (e.g. data for a specific subject on a trial)
|
| CCTS-CDH-504 | Cross-domain hot-links may that leverage search capabilities present in the target application should perform the search without the user having to take further action (e.g. click a search button)
|
C3D Connector
C3PR
caAERS
caXchange
LabViewer
PSC
