**Security & Regulatory Requirements**

caBIG®

CCTS

(Cancer Clinical Trials Suite)

System Version: v1.0

Document Revision: v0.4

  ----------------------------------- -----------------------------------
  System Owner:                       

  Business Area:                      

  System Responsible:                 

  Business Area:                      
  ----------------------------------- -----------------------------------

DOCUMENT CHANGE HISTORY

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

  0.1          9/5/2008       Initial draft

  0.2          9/8/2008       Incorporate input from CCTS technical SMEs
                              and legal clients

  0.3          9/9/2008       Add Draft watermark and footer.

  0.4          9/11/2008      Incorporate input in Data Requireqments
                              section, ...
  ------------ -------------- -------------------------------------------

TABLE OF CONTENTS

**1.** **Overview and Objective [2](#overview-and-objective)**

2\. Scope [2](#scope)

3\. Reference Documents [2](#reference-documents)

CCTS Architecture Document (Extended): Current Version plus Gap Analysis
[2](#__RefHeading___Toc208830395)

4\. Business Justification [4](#business-justification)

4.1 Purpose [4](#purpose)

4.2 Constraints [4](#constraints)

5\. Requirements [5](#requirements)

5.1 Vocabularies [5](#vocabularies)

5.2 Data Definitions [5](#data-definitions)

5.2.1 Protected Health Information (PHI)
[5](#protected-health-information-phi)

5.2.2 De-Identified Data (de-ID) [6](#de-identified-data-de-id)

5.2.3 Limited Data Set [6](#limited-data-set)

5.2.4 Intellectual Property (IP) [6](#intellectual-property-ip)

5.2.5 Federated Data [6](#federated-data)

5.2.6 Consent Forms [7](#consent-forms)

5.2.7 Physical Control [7](#physical-control)

5.2.8 Transaction Logs [7](#transaction-logs)

5.3 Levels of Assurance [7](#levels-of-assurance)

5.4 Roles [8](#roles)

5.5 non-functional requirements [9](#non-functional-requirements)

5.5.1 General Requirements [9](#general-requirements)

5.5.2 Auditing [9](#auditing)

5.5.3 Data Requirements [10](#data-requirements)

5.5.4 GUI Specifications -- Section 508 of the Rehabilitation Act
[11](#gui-specifications-section-508-of-the-rehabilitation-act)

5.5.5 Security [12](#security)

5.5.6 Regulatory -- HIPAA [13](#regulatory-hipaa)

5.5.7 Regulatory -- Intellectual Property
[14](#regulatory-intellectual-property)

5.5.8 Regulatory -- GxP System [15](#regulatory-gxp-system)

5.5.9 Regulatory -- 21 CFR Part 11 [15](#regulatory-21-cfr-part-11)

5.5.10 Regulatory -- Predicate Rules [16](#regulatory-predicate-rules)

5.5.11 Regulatory -- FISMA [16](#regulatory-fisma)

5.5.12 Regulatory -- NIST guidelines [16](#regulatory-nist-guidelines)

5.5.13 Regulatory -- HHS Secure One [17](#regulatory-hhs-secure-one)

Appendix A -- Acronym List [18](#appendix-a-acronym-list)

# Overview and Objective

> This Security and Regulatory Requirements Specification (SRRS) is
> intended to document the security and regulatory requirements for the
> Biomedical Informatics Grid (caBIG®) Cancer Clinical Trials Suite
> (CCTS).
>
> caBIG® completed v1.0 of the Clinical Trials Suite (CCTS) in Q1 '08
> without explicitly incorporating the legal, regulatory, or
> intellectual property requirements that impact data exchange. This gap
> is mitigated somewhat by the control mechanisms provided in the caGRID
> services, including authentication and authorization.
>
> The objective of these requirements is to provide guidance regarding:
> HIPAA (including the Security and Privacy Rules), FISMA, NIST
> guidelines, HHS Secure One, FDA rules, intellectual property (IP), and
> other areas of law, regulation, and policy. These requirements will be
> traced through to the functionality in the applications to identify
> any gaps or areas of concern.

# Scope

> This document establishes the National Cancer Institute's business and
> technical requirements for the caBIG® Clinical Trials Suite (CCTS).
> Using CCTS v1.0 as the basis, it will also by influenced by v1.1, the
> COPPA project, and the new and enhanced use cases planned for the next
> major version, currently thought to be v1.5 or v2.0.

# Reference Documents

> For additional CCTS or legal information, refer to the following
> documents:

+-----------------+--------+-------------------------------------------+
| Document or     | Date   | Title or Guidance Location                |
| Organization    |        |                                           |
| Name            |        |                                           |
+=================+========+===========================================+
| [               |        | Not found on gForge or Wiki.              |
| ]{#__RefHeading |        |                                           |
| ___Toc208830395 |        |                                           |
| .anchor}CCTS    |        |                                           |
| Architecture    |        |                                           |
| Document        |        |                                           |
| (Extended):     |        |                                           |
| Current Version |        |                                           |
| plus Gap        |        |                                           |
| Analysis        |        |                                           |
+-----------------+--------+-------------------------------------------+
| CCTS Software   | July   | <https://gforge.nci.ni                    |
| Product         | 27,    | h.gov/plugins/scmsvn/viewcvs.php/trunk/cc |
| Specification   | 2007   | ts/documentation/requirements/?root=ccts> |
| Document        |        |                                           |
+-----------------+--------+-------------------------------------------+
| DSSF            | May    | The caBIG™ Data Sharing and Security      |
|                 | 16,    | Framework presentation                    |
|                 | 2008   |                                           |
+-----------------+--------+-------------------------------------------+
| FDA Regulations |        | Food and Drug Administration:             |
|                 |        | <http://fda.com/>                         |
+-----------------+--------+-------------------------------------------+
| FISMA           | 2002   | Federal Information Security Management   |
|                 |        | Act of 2002 (\"FISMA\", [44               |
|                 |        | U.S.C.]                                   |
|                 |        | (http://en.wikipedia.org/wiki/Title_44_of |
|                 |        | _the_United_States_Code) [§ 3541](http:// |
|                 |        | www.law.cornell.edu/uscode/44/3541.html), |
|                 |        | et seq.) is a [United States federal      |
|                 |        | law](http://en.wiki                       |
|                 |        | pedia.org/wiki/United_States_federal_law) |
|                 |        | enacted in 2002 as Title III of the       |
|                 |        | [E-Government Act of                      |
|                 |        | 2002](http://en.wik                       |
|                 |        | ipedia.org/wiki/E-Government_Act_of_2002) |
|                 |        | ([Pub.L.                                  |
|                 |        | 107-347](http://frwebgate.a               |
|                 |        | ccess.gpo.gov/cgi-bin/getdoc.cgi?dbname=1 |
|                 |        | 07_cong_public_laws&docid=f:publ347.107), |
|                 |        | 116 [Stat.](http://en.wikipedia.org/wik   |
|                 |        | i/United_States_Statutes_at_Large) 2899). |
|                 |        | The act was meant to bolster computer and |
|                 |        | network security within the federal       |
|                 |        | government and affiliated parties (such   |
|                 |        | as [government                            |
|                 |        | contractors](http://en.                   |
|                 |        | wikipedia.org/wiki/Government_contracts)) |
|                 |        | by mandating yearly                       |
|                 |        | [audi                                     |
|                 |        | ts](http://en.wikipedia.org/wiki/Audits). |
|                 |        |                                           |
|                 |        | FISMA imposes a mandatory set of          |
|                 |        | processes that must be followed for all   |
|                 |        | information systems used or operated by a |
|                 |        | U.S. federal government agency or by a    |
|                 |        | contractor or other organization on       |
|                 |        | behalf of a federal agency. These         |
|                 |        | processes must follow a combination of    |
|                 |        | Federal Information Processing Standards  |
|                 |        | (FIPS) documents, the special             |
|                 |        | publications SP-800 series issued by      |
|                 |        | [                                         |
|                 |        | NIST](http://en.wikipedia.org/wiki/NIST), |
|                 |        | and other legislation pertinent to        |
|                 |        | federal information systems, such as the  |
|                 |        | [Privacy Act of                           |
|                 |        | 1974](http://e                            |
|                 |        | n.wikipedia.org/wiki/Privacy_Act_of_1974) |
|                 |        | and the [Health Insurance Portability and |
|                 |        | Accountability                            |
|                 |        | Act](                                     |
|                 |        | http://en.wikipedia.org/wiki/Health_Insur |
|                 |        | ance_Portability_and_Accountability_Act). |
|                 |        | \[<h                                      |
|                 |        | ttp://en.wikipedia.org/wiki/Federal_Infor |
|                 |        | mation_Security_Management_Act_of_2002>\] |
|                 |        |                                           |
|                 |        | See                                       |
|                 |        | <http://c                                 |
|                 |        | src.nist.gov/groups/SMA/fisma/index.html> |
+-----------------+--------+-------------------------------------------+
| HHS Secure One  | Dec.   | HHS's Information Security Program        |
|                 | 15,    | Policy:                                   |
|                 | 2004   | <http://                                  |
|                 |        | ftp.fas.org/sgp/othergov/hhs-infosec.pdf> |
+-----------------+--------+-------------------------------------------+
| Health          | 1996   | <http://www.hipaa.org/>                   |
| Insurance       |        |                                           |
| Portability and |        | For the HIPAA Guidelines written by the   |
|                 |        | Clinical Imaging Data Sharing group, see  |
| Accountability  |        | <https://wiki.nci.nih.gov/display/Cli     |
| Act (HIPAA)     |        | nicalImagingDataSharing/HIPAA+guideline>. |
+-----------------+--------+-------------------------------------------+
| NIST Guidelines |        | National Institute of Standards and       |
|                 |        | Technology: <http://www.nist.gov/>        |
+-----------------+--------+-------------------------------------------+
| Section 508 of  | 1973   | "Section 508 requires that Federal        |
| the             |        | agencies\' electronic and information     |
| Rehabilitation  |        | technology is accessible to people with   |
| Act             |        | disabilities. IT Accessibility &          |
|                 |        | Workforce Division, in the U.S. General   |
|                 |        | Services Administration\'s Office of      |
|                 |        | Governmentwide Policy, has been charged   |
|                 |        | with the task of educating Federal        |
|                 |        | employees and building the infrastructure |
|                 |        | necessary to support Section 508          |
|                 |        | implementation. Using their web site,     |
|                 |        | Federal employees and the public can      |
|                 |        | access resources for understanding and    |
|                 |        | implementing the requirements of Section  |
|                 |        | 508." \-- from                            |
|                 |        | <http://www.section508.gov/>              |
+-----------------+--------+-------------------------------------------+

# Business Justification

## Purpose

> The CCTS has been developed under the auspices of the Clinical Trials
> Management Systems Workspace of the Cancer Biomedical Informatics Grid
> (caBIG®), an NCI enterprise program overseen by the NCI's Center for
> Bioinformatics and Information Technology (CBIIT). The goal of the
> caBIG® program is to accelerate research discoveries and improve
> patient outcomes by linking researchers, physicians, and patients
> throughout the cancer community. caBIG® serves as the cornerstone of
> NCI's biomedical informatics efforts to transform cancer research into
> a more collaborative, efficient, and effective endeavor.
>
> The CCTS is a modular Clinical Trials Management System (CTMS),
> consisting of a suite of interoperable tools designed to facilitate
> the management of clinical trials, especially in (but not limited to)
> the context of the National Cancer Institute (NCI)-supported cancer
> research community. The tools can be used as standalone applications,
> or collectively as an interoperable suite.[^1]

## Constraints

a)  The caBIG® community has decided to adopt the HL7-CDISC data model
    as the initial one for caGRID development. This step will have an
    impact on the process of reconciling data elements with the caDSR as
    well as outside the caBIG® community. It is imperative that a
    process for working with HL7 and CDISC be outlined as soon as
    possible in addition to establishing a framework for gaining
    consensus regarding data elements within our own community.

b)  All systems developed in the CTMS workspace must conform to HIPAA
    requirements and follow other accepted guidelines such as Title 21
    Code of Federal Regulations (21 CFR Part 11) for FDA acceptance of
    electronic records and signatures.

c)  The Correlation Organization Person Protocol Abstraction (COPPA)
    project is currently in the process of defining, scoping, designing,
    and building the CTMS/ caBIG® four core services: Person,
    Organization, Protocol Abstraction, and Correlation. These services
    will be consumed by applications being built in the CTMS workspace.
    Given that this project is underway, the security and regulatory
    requirements will be derived from anticipated changes based on these
    new services.

# Requirements

## Vocabularies

> 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  Req. Name        Requirement Description

  VR01    Ensure caDSR     CCTS will leverage Enterprise Vocabulary
          Compliance       Services (EVS) and Cancer Data Standards
                           Repository (caDSR) wherever possible and
                           appropriate.

  VR02    Enable Use of    CCTS will enable data conversion from CTCAE to
          MedDRA           MedDRA.

  VR03    Enable Use of    CCTS will enable data capture using CTCAE.
          CTCAE            
  ------- ---------------- ----------------------------------------------

###  {#section .unnumbered}

## Data Definitions

### Protected Health Information (PHI)

> Protected data is any record that contains personal medical or health
> information accompanied by ANY of the following:
>
> 1\. Names.\
> 2. All geographic subdivisions smaller than a state, including street
> address, city, county, precinct, ZIP Code, and their equivalent
> geographical codes, except for the initial three digits of ZIP Code
> if, according to the current publicly available data from the Bureau
> of the Census:\
> a. The geographic unit formed by combining all ZIP Codes with the same
> three initial digits contains more than 20,000 people.\
> b. The initial three digits of a ZIP Code for all such geographic
> units containing 20,000 or fewer people are changed to 000.\
> 3. All elements of dates (except year) for dates directly related to
> an individual, including birth date, admission date, discharge date,
> date of death; and all ages over 89 and all elements of dates
> (including year) indicative of such age, except that such ages and
> elements may be aggregated into a single category of age 90 or older.\
> 4. Telephone numbers.\
> 5. Facsimile numbers.\
> 6. Electronic mail addresses.\
> 7. Social security numbers.\
> 8. Medical record numbers.\
> 9. Health plan beneficiary numbers.\
> 10. Account numbers.\
> 11. Certificate/license numbers.\
> 12. Vehicle identifiers and serial numbers, including license plate
> numbers.\
> 13. Device identifiers and serial numbers.\
> 14. Web universal resource locators (URLs).\
> 15. Internet protocol (IP) address numbers.\
> 16. Biometric identifiers, including fingerprints and voiceprints.\
> 17. Full-face photographic images and any comparable images.\
> 18. Any other unique identifying number, characteristic, or code,
> unless otherwise permitted by the Privacy Rule for re-identification.
> \[Jaffe\]

### De-Identified Data (de-ID)

> De-identified data is any record containing personal health or medical
> information with ALL of the above listed identifiers removed.
> Alternatively, data may be de-identified using statistical methods.
>
> The covered entity may obtain certification by 'a person with
> appropriate knowledge of and experience with generally accepted
> statistical and scientific principles and methods for rendering
> information not individually identifiable\" that there is a \"very
> small\" risk that the information could be used by the recipient to
> identify the individual who is the subject of the information, alone
> or in combination with other reasonably available information. The
> person certifying statistical de-identification must document the
> methods used as well as the result of the analysis that justifies the
> determination. A covered entity is required to keep such
> certification, in written or electronic format, for at least 6 years
> from the date of its creation or the date when it was last in effect,
> whichever is later. \[Jaffe\]

### Limited Data Set

> A limited data set is similar to a de-identified data set but may
> include geographic information other than street address, dates/ages,
> and other uniquely identifying numbers, characteristics or codes. An
> LDS may be shared with researchers who sign a data use agreement to
> assure that they will:

-   Use the data only for the designated research

```{=html}
<!-- -->
```
-   Protect the data against inappropriate disclosure

```{=html}
<!-- -->
```
-   Not use the information to re-identify the included individuals
    \[DSIC\]

### Intellectual Property (IP) 

> "Intellectual property refers to creations of the mind: inventions,
> literary and artistic works, and symbols, names, images, and designs
> used in commerce... Industrial property, which includes inventions
> (patents), trademarks, industrial designs, and geographic indications
> of source." \[[What is Intellectual
> Property?](http://www.wipo.int/about-ip/en/), World Intellectual
> Property Organization.\]

### Federated Data 

> A federated database connects multiple autonomous database systems
> through a computer network, allowing a user the appearance of
> accessing a single database. The autonomous databases may be
> geographically decentralized.

### Consent Forms 

> A patient participating in a clinical trial must sign a written
> Authorization for as required by the IRB for that trial. The IRB /
> authorization form may impose further restrictions to sharing PHI if
> the participants involved in the trial.

### Physical Control 

> Physical control of a database containing PHI must be maintained
> according to FDA requirements.

### Transaction Logs 

> Logs of messages sent within a system or between systems must be
> maintained according to FDA regulations.

## Levels of Assurance

> Level of assurance is a provides regulations for online government
> services and Identity Providers are rated on a scale of 1 to 4, with 1
> being low and 4 being high, depending upon several factors, including
> the necessity to protect data. The assurance level of the Identity
> Provider must be equal to or higher than the assurance level of the
> online government service that the end user is trying to use. \[see
> <http://asc.gsa.gov/portal/template/faq12.vm;jsessionid=E91AE99D3C6456320AAC308DF103505D>\]
>
> In the CCTS suite, the LOA value is determined by:

-   IP Value

-   Sensitivity of data

-   IRB restrictions

-   Sponsor restrictions

> A page of any application qualifies for general website terms of use
> if it contains ALL of the following:

-   no IP value

-   low sensitivity data

-   no IRB restrictions

-   no sponsor restrictions

> A page of any application requires standardized click-though terms and
> conditions if it contains ANY of the following:

-   moderate IP value

-   moderate sensitivity data (e.g. LDS)

-   limited institutional or IRB policy restrictions

-   moderate sponsor restrictions

> A page of any application requires standardized click-through terms
> and conditions *or* individually negotiated bi-lateral or
> multi-lateral agreement if it contains ANY of the following:

-   high IP value

-   high sensitivity data (e.g. PHI)

-   significant IRB consent restrictions

-   major sponsor restrictions. \[DSIC, slide 14\]

+--------+----------------+--------------------------------------------+
| *      | **Data         | **caBIG™ Security Policies/Procedures**    |
| *Level | Sensitivity    |                                            |
| of     | Level**        |                                            |
| Assur  |                |                                            |
| ance** |                |                                            |
+========+================+============================================+
| **LOA  | Low            | caGrid Level 1 Host Trust Agreement for    |
| 1**    | sensitivity    | Interfederation (to bring new identity     |
|        | data (no IP    | providers into the trust federation)       |
|        | value, no IRB  |                                            |
|        | or sponsor     | LOA1 caGrid Certificate Policy and         |
|        | restrictions)  | Practice Statement                         |
+--------+----------------+--------------------------------------------+
| **LOA  | Moderate       | LOA2 caGrid Certificate Policy and         |
| 2**    | sensitivity    | Practice Statement                         |
|        | data           |                                            |
|        | (deidentified  | Underway: LOA2 caGrid Level 2 Host Trust   |
|        | data, Limited  | Agreement and pilot Technical              |
|        | Data Sets,     | Implementation at an academic institution  |
|        | moderate IP    | (UT)                                       |
|        | value and      |                                            |
|        | moderate       |                                            |
|        | inst           |                                            |
|        | itutional/IRB/ |                                            |
|        | sponsor        |                                            |
|        | restrictions)  |                                            |
+--------+----------------+--------------------------------------------+

## Roles

> Each application must maintain the ability to restrict data access
> based on the role of an authenticated user. Any role requiring
> restricted access (LOA2-LOA4 as defined above) must follow NIST
> guidelines in allowing access for Create/Read/Update/Delete (CRUD)
> access to a role. Access to data may be further restricted locally,
> for instance by local laws, institutional rules or IRB requirements. A
> role's access to data must be able to be modified to reflect these
> restrictions.
>
> Each application must specify a role with CRUD access for IP sensitive
> data (LOA2).
>
> Each application must specify a role with CRUD access for PHI
> sensitive data (LOA2).
>
> The following table contains the different kinds of user groups
> required for each application that contains PHI or IP data.

+----------+-----------------------------------------------------------+
| **Role** | **Criteria**                                              |
+==========+===========================================================+
| **System | "Super-user\" with the highest level of access to the     |
| Adminis  | system.                                                   |
| trator** |                                                           |
|          | -   Manages the application                               |
|          |                                                           |
|          | -   Approves and manages user registration process        |
|          |                                                           |
|          | -   Grants users to a role within the application         |
+----------+-----------------------------------------------------------+
| **Study  | Access limited to administration of all studies.          |
| Adminis  |                                                           |
| trator** | -   Reviews completed Study definitions to determine if   |
|          |     they are complete and correct                         |
|          |                                                           |
|          | -   Determines which studies will be editable/viewable    |
|          |     for each Clinical Research Coordinator and viewable   |
|          |     for each Research Associate                           |
+----------+-----------------------------------------------------------+
| **Study  | Access limited to administration of assigned studies.     |
| Coord    |                                                           |
| inator** | -   Creates new Study definitions in the system           |
+----------+-----------------------------------------------------------+
| **Reg    | Access limited to administration of all users and all     |
| istrar** | studies.                                                  |
|          |                                                           |
|          | -   Enrolls Participants to Studies for which approval    |
|          |     has been granted                                      |
+----------+-----------------------------------------------------------+

## non-functional requirements

### General Requirements

  -------------------------------------------------------------------------
  **Req. ID**    **Req. Name**   **Requirement**
  -------------- --------------- ------------------------------------------
  NFR-GEN-0001   caGRID Services All systems that share data shall develop
                                 an analytical service and be deployed to
                                 interact with caGrid services.

  NFR-GEN-0002   caDSR           All web interfaces within system shall be
                                 driven by metadata registered in the
                                 caDSR.

  NFR-GEN-0003   CSM             The systems must comply with the caBIG®
                                 Common Security Model.

  NFR-GEN-0004   DSIC            System developers must adhere to the
                                 caBIG® Data Sharing & Intellectual Capital
                                 (DSIC) Policy and Procedures.

  NFR-GEN-0005   BRIDG           The system must comply with the Biomedical
                 Compatibility   Research Integrated Domain Group (BRIDG)
                                 model.

  NFR-GEN-0006   Messaging       The messaging format will be HL7 and must
                 Compatibility   remain harmonized with the evolution of
                                 this convention.
  -------------------------------------------------------------------------

### Auditing

> The system must capture transactional data in an auditable format that
> includes each 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 ID         Req. Name     Requirement Description
  -------------- ------------- --------------------------------------------
  NFR-AUD-0001   Required      Each CCTS module will capture required audit
                 audit         information (see list above).
                 information   

  NFR-AUD-0002   Timely Access Auditing information must be accessible in a
                               timely manner to system administrators.

  NFR-AUD-0003   Audit         Auditing features must at least be available
                 Features      through standard database logging/auditing.

  NFR-AUD-0004   No Deletion   Records will be marked as deleted, but data
                 of Data       will never be deleted once it has been
                               entered into the system.
  -------------------------------------------------------------------------

### Data Requirements

> This section defines the access and exchange requirements for data
> elements in the system, as well as requirements related to the dataset
> itself. Refer back to Section 5: Data Definitions for the supporting
> definitions.

#### Data Access

  -------------------------------------------------------------------------
  **Req ID**    **Req. Name**  **Requirement Description**
  ------------- -------------- --------------------------------------------
  NFR-DA-0001   PHI to De-Id   The system must be able to de-identify PHI
                               data regardless of institution.

  NFR-DA-0002   PHI to LDS     The system must be able to limit PHI data to
                               LDS data regardless of institution.

  NFR-DA-0003   IRB            The system must be able to modify displayed
                requirements   data based on individual IRB requirements.

  NFR-DA-0004   Restricting    The system must be able to restrict CRUD
                data           access to data according to PHI
                               requirements, IP concerns, or a combination.
                               Data that is restricted by a combination of
                               PHI and IP requirements must limit access to
                               the more restrictive requirement as defined
                               by the DSIC Worksheet.

  NFR-DA-0005   PHI role       The system must include a role that allows
                access         PHI CRUD access for each LOA required by the
                requirements   functionality of the system.

  NFR-DA-0006   IP role access The system must include a role that allows
                requirements   IP CRUD access for each LOA required by the
                               functionality of the system.

  NFR-DA-0007   Restricting    The system must be able to role restrict
                data by role   CRUD access to data. Data restrictions may
                               be required by PHI restrictions or IP
                               concerns or both.

  NFR-DA-0008   Restricting    The system must restrict CRUD access to data
                data by IP and so that a role must have sufficient PHI and
                PHI            IP LOA to access any restricted data.

  NFR-DA-0009   Restricting IP The system must authenticate access to IP
                data           data at the individual study level.

  NFR-DA-0010   Restricting    The system must authenticate access to PHI
                PHI data       data at the individual study level.

  NFR-DA-0011   Sharing        The system must implement a method of
                restricted     sharing IP or PHI restricted data between
                data           individual parties when a contract exists
                               between the data donor and the data
                               recipient. The data donor must own the right
                               to share the data.

  NFR-DA-0012   Releasing IP   The system must implement a method of
                data           changing restrictions of IP data in
                               accordance with the changing nature of the
                               IP value of the data.

  NFR-DA-0013   Release        The system must be able to restrict PHI CRUD
                consent forms  access if the system lacks confirmation of a
                               signed release consent.

  NFR-DA-0014   Federated data The system must encrypt any PHI or IP data
                               that passes outside an institution's
                               firewall.

  NFR-DA-0015   Display of low The system must implement display of low
                sensitivity    sensitivity data (no IP value, low
                data           sensitivity health data, no IRB
                               restrictions, no sponsor restrictions).
  -------------------------------------------------------------------------

#### Data Exchange

  ------------------------------------------------------------------------
  Req ID        Req. Name     Requirement Description
  ------------- ------------- --------------------------------------------
  NFR-DE-0001   XML Data      The standard mechanism for exchanging data
                Exchange      with a CCTS instance will be XML.

  NFR-DE-0002   Data Import   CCTS will expose APIs for data import.
                API           

  NFR-DE-0003   CCTS Data     Separate CCTS installations will be able to
                Exchange      exchange data with each other via XML.

  NFR-DE-0004   Share         Adopters will be able to exchange Rulesets
                Triggers      so that all users under a certain sponsor
                              can use the same Rulesets. These will be
                              sent in XML format.
  ------------------------------------------------------------------------

###  {#section-1 .unnumbered}

### GUI Specifications -- Section 508 of the Rehabilitation Act

> Per the purpose of Section 508 stated on the website: "The purpose of
> this part is to implement section 508 of the Rehabilitation Act of
> 1973, as amended (29 U.S.C. 794d). Section 508 requires that when
> Federal agencies develop, procure, maintain, or use electronic and
> information technology, Federal employees with disabilities have
> access to and use of information and data that is comparable to the
> access and use by Federal employees who are not individuals with
> disabilities, unless an undue burden would be imposed on the agency.
> Section 508 also requires that individuals with disabilities, who are
> members of the public seeking information or services from a Federal
> agency, have access to and use of information and data that is
> comparable to that provided to the public who are not individuals with
> disabilities, unless an undue burden would be imposed on the agency."

  ---------------------------------------------------------------------------------------
  Req ID                  Req. Name        Requirement Description
  ----------------------- ---------------- ----------------------------------------------
  NFR-GUI-0001            Non-text         A text equivalent for every non-text element
                          Elements         shall be provided (e.g., via \"alt\",
                                           \"longdesc\", or in element content).

  [NFR-GUI-0002]{.mark}   []{.mark}        [Equivalent alternatives for any multimedia
                                           presentation shall be synchronized with the
                                           presentation.]{.mark}

  [NFR-GUI-0003]{.mark}   []{.mark}        [Web pages shall be designed so that all
                                           information conveyed with color is also
                                           available without color, for example from
                                           context or markup.]{.mark}

  [NFR-GUI-0004]{.mark}   []{.mark}        [Documents shall be organized so they are
                                           readable without requiring an associated style
                                           sheet.]{.mark}

  [NFR-GUI-0005]{.mark}   []{.mark}        [Redundant text links shall be provided for
                                           each active region of a server-side image
                                           map.]{.mark}

  [NFR-GUI-0006]{.mark}   []{.mark}        [Client-side image maps shall be provided
                                           instead of server-side image maps except where
                                           the regions cannot be defined with an
                                           available geometric shape.]{.mark}

  NFR-GUI-0007            Row/column       Row and column headers shall be identified for
                          Headers          data tables.

  [NFR-GUI-0008]{.mark}   []{.mark}        [Markup shall be used to associate data cells
                                           and header cells for data tables that have two
                                           or more logical levels of row or column
                                           headers.]{.mark}

  NFR-GUI-0009            Frame            Frames shall be titled with text that
                          Identification   facilitates frame identification and
                                           navigation.

  NFR-GUI-0010            Screen           Pages shall be designed to avoid causing the
                          Resolution       screen to flicker with a frequency greater
                                           than 2 Hz and lower than 55 Hz.

  [NFR-GUI-0011]{.mark}   []{.mark}        [A text-only page, with equivalent information
                                           or functionality, shall be provided to make a
                                           web site comply with the provisions of this
                                           part, when compliance cannot be accomplished
                                           in any other way. The content of the text-only
                                           page shall be updated whenever the primary
                                           page changes.]{.mark}

  [NFR-GUI-0012]{.mark}   []{.mark}        [When pages utilize scripting languages to
                                           display content, or to create interface
                                           elements, the information provided by the
                                           script shall be identified with functional
                                           text that can be read by assistive
                                           technology.]{.mark}

  [NFR-GUI-0013]{.mark}   []{.mark}        [When a web page requires that an applet,
                                           plug-in or other application be present on the
                                           client system to interpret page content, the
                                           page must provide a link to a plug-in or
                                           applet that complies with §1194.21(a) through
                                           (l).]{.mark}

  [NFR-GUI-0014]{.mark}   []{.mark}        [When electronic forms are designed to be
                                           completed on-line, the form shall allow people
                                           using assistive technology to access the
                                           information, field elements, and functionality
                                           required for completion and submission of the
                                           form, including all directions and
                                           cues.]{.mark}

  NFR-GUI-0015            Skip Repetitive  A method shall be provided that permits users
                          Navigation Links to skip repetitive navigation links.

  NFR-GUI-0016            Timed Response   When a timed response is required, the user
                                           shall be alerted and given sufficient time to
                                           indicate more time is required.
  ---------------------------------------------------------------------------------------

###  {#section-2 .unnumbered}

### Security

> The following is a list of security requirements supported by the Role
> section above:

  ------------------------------------------------------------------------------
  Req ID         Req. Name        Requirement Description
  -------------- ---------------- ----------------------------------------------
  NFR-SEC-0001   Create User      Only the System Administrator will create user
                 Accounts         accounts.

  NFR-SEC-0002   Assign Role to   Only the System Administrator will assign one
                 User Accounts    or more roles to each user account.

  NFR-SEC-0003   Enforce Access   The application must ensure that users are
                 Control          only able to access data and functionality
                                  that has been granted to their roles and/or
                                  account.

  NFR-SEC-0004   Forgotten        If a user forgets his or her password, the
                 Passwords        system will be able to create a new password
                                  for that user.

  NFR-SEC-0005   caGrid 1.0-based The system must implement authentication using
                 authentication   caGrid 1.0 security infrastructure. This will
                                  facilitate the use of existing institutional
                                  identity providers.

  NFR-SEC-0005   caGrid 1.0-based The system must implement authorization/access
                 authorization    control using caGrid 1.0 security
                                  infrastructure.
  ------------------------------------------------------------------------------

###  {#section-3 .unnumbered}

### Regulatory -- HIPAA

> There are three broad classes of HIPAA requirements:
>
> **HIPAA Privacy Rule -** The HIPPA Privacy Rule mandates the
> protection and privacy of all health information. This rule
> specifically defines the authorized uses and disclosures of
> \"individually-identifiable\" health information.
>
> **HIPAA Transactions and Code Set Rule -** The HIPPA Transaction and
> Code Set Standard addresses the use of predefined transaction
> standards and code sets for communications and transactions in the
> health-care industry.
>
> **HIPAA Security Rule -** The HIPAA Security Rule mandates the
> security of electronic medical records. Unlike the Privacy Rule, which
> provides broader protection for all formats that health information
> make take, such as print or electronic information, the Security Rule
> addresses the technical aspects of protecting electronic health
> information. More specifically, the HIPPA Security standards addresses
> these aspects of security:
>
> **- Administrative security** -- assignment of security responsibility
> to an individual. 
>
> **- Physical security** - required to protect electronic systems,
> equipment and data.
>
> **- Technical security** - authentication & encryption used to control
> access to data.
>
> While CCTS will be designed to support all the applicable HIPAA
> requirements, the burden for ensuring that the use of CCTS is in
> compliance resides with the adopting institution. That is, it is the
> responsibility of the institution to ensure that the necessary
> business, technical, and security policies and procedures are put into
> effect and enforced and that the necessary physical security
> safeguards are in place.

  -----------------------------------------------------------------------------
  Req ID         Req. Name        Requirement Description
  -------------- ---------------- ---------------------------------------------
  NFR-HIP-0001   Access Control   Include mechanism to allow access only to
                                  those persons or software programs that are
                                  authorized.

  NFR-HIP-0002   Unique User      Assign a unique name and/or number for
                 Identification   tracking user identity.

  NFR-HIP-0003   Emergency Access Establish procedures for obtaining necessary
                 Procedure        electronic protected health information
                                  during an emergency.

  NFR-HIP-0004   Automatic Logoff Include mechanism that terminates an
                                  electronic session after a predetermined time
                                  of inactivity.

  NFR-HIP-0005   Encryption and   Include mechanism to encypt and decrypt
                 Decryption       electronic protected health information.

  NFR-HIP-0006   Audit Controls   Include mechanism that records and examines
                                  activity in information systems that contain
                                  or use electronically protected health
                                  information.

  NFR-HIP-0007   Integrity        Implement mechanism to protect electronic
                                  protected health information from improper
                                  alteration or destruction.

  NFR-HIP-0008   Authenticate     Include mechanism to corroborate that
                 Electronic       electronic protected information has not been
                 Protected Health altered or destroyed in an unauthorized
                 Information      manner.

  NFR-HIP-0009   Person or Entity Include mechanism to verify that person or
                 Authentication   entity seeking access to electronic protected
                                  health information is the one claimed.

  NFR-HIP-0010   Transmission     Include mechanism to guard against
                 Security         unauthorized access to electronic protected
                                  health information that is being transmitted
                                  over an electronic communications network.

  NFR-HIP-0011   Integrity        Include mechanism to ensure electronically
                 Controls         transmitted electronic protected health
                                  information is not improperly modified
                                  without detection until disposed of.

  NFR-HIP-0012   Encryption       Include mechanism to encrypt electronic
                                  protected health information whenever deemed
                                  appropriate.
  -----------------------------------------------------------------------------

###  {#section-4 .unnumbered}

### Regulatory -- Intellectual Property

  -------------------------------------------------------------------------
  Req ID        Req. Name     Requirement Description
  ------------- ------------- ---------------------------------------------
  NFR-IP-0001                 

  NFR-IP-0002                 

  NFR-IP-0003                 

  NFR-IP-0004                 

  NFR-IP-0005                 

  NFR-IP-0006                 

  NFR-IP-0007                 

  NFR-IP-0008                 
  -------------------------------------------------------------------------

###  {#section-5 .unnumbered}

### Regulatory -- GxP System

  --------------------------------------------------------------------------
  Req ID         Req. Name     Requirement Description
  -------------- ------------- ---------------------------------------------
  NFR-GxP-0001                 

  NFR-GxP-0002                 

  NFR-GxP-0003                 

  NFR-GxP-0004                 

  NFR-GxP-0005                 

  NFR-GxP-0006                 

  NFR-GxP-0007                 

  NFR-GxP-0008                 
  --------------------------------------------------------------------------

###  {#section-6 .unnumbered}

### Regulatory -- 21 CFR Part 11 

> The following 21 CFR Part 11 requirements are predicated on the use of
> electronic signatures, where they are required for identification of
> the user for specific activities.

+-----------+------------+---------------------------------------------+
| Req ID    | Req. Name  | Requirement Description                     |
+===========+============+=============================================+
| NFR-      |            | \(a\) Electronic signatures that are not    |
| P11-0001a |            | based upon biometrics shall                 |
+-----------+------------+---------------------------------------------+
| NFR-P1    |            | > \(1\) Employ at least two distinct        |
| 1-0001a-1 |            | > identification components such as an      |
|           |            | > identification code and password.         |
+-----------+------------+---------------------------------------------+
| NFR-P11-  |            | > \(i\) When an individual executes a       |
| 0001a-1-i |            | > series of signings during a single,       |
|           |            | > continuous period of controlled system    |
|           |            | > access, the first signing shall be        |
|           |            | > executed using all electronic signature   |
|           |            | > components; subsequent signings shall be  |
|           |            | > executed using at least one electronic    |
|           |            | > signature component that is only          |
|           |            | > executable by, and designed to be use     |
|           |            | > only by, the individual.                  |
+-----------+------------+---------------------------------------------+
| NFR-P11-0 |            | > \(ii\) When an individual executes one or |
| 001a-1-ii |            | > more signings not performed during a      |
|           |            | > single, continuous period of controlled   |
|           |            | > system access, each signing shall be      |
|           |            | > executed using all of the electronic      |
|           |            | > signature components.                     |
+-----------+------------+---------------------------------------------+
| NFR       |            | > \(2\) Be used only by their genuine       |
| -P11-0002 |            | > owners; and                               |
+-----------+------------+---------------------------------------------+
| NFR       |            | > \(3\) Be administered and executed to     |
| -P11-0003 |            | > ensure that attempted use of an           |
|           |            | > individual\'s electronic signature by     |
|           |            | > anyone other than its genuine owner       |
|           |            | > requires collaboration of two or more     |
|           |            | > individuals.                              |
+-----------+------------+---------------------------------------------+
| NFR       |            | \(b\) Electronic signatures based upon      |
| -P11-0004 |            | biometrics shall be designed to ensure that |
|           |            | they cannot be used by anyone other than    |
|           |            | their genuine owners.                       |
+-----------+------------+---------------------------------------------+

###  {#section-7 .unnumbered}

### Regulatory -- Predicate Rules

  -------------------------------------------------------------------------
  Req ID        Req. Name     Requirement Description
  ------------- ------------- ---------------------------------------------
  NFR-PR-0001                 

  NFR-PR-0002                 

  NFR-PR-0003                 

  NFR-PR-0004                 

  NFR-PR-0005                 

  NFR-PR-0006                 

  NFR-PR-0007                 

  NFR-PR-0008                 
  -------------------------------------------------------------------------

###  {#section-8 .unnumbered}

### Regulatory -- FISMA

  --------------------------------------------------------------------------
  Req ID         Req. Name     Requirement Description
  -------------- ------------- ---------------------------------------------
  NFR-FIS-0001                 

  NFR-FIS-0002                 

  NFR-FIS-0003                 

  NFR-FIS-0004                 

  NFR-FIS-0005                 

  NFR-FIS-0006                 

  NFR-FIS-0007                 

  NFR-FIS-0008                 
  --------------------------------------------------------------------------

###  {#section-9 .unnumbered}

### Regulatory -- NIST guidelines

  ---------------------------------------------------------------------------
  Req ID          Req. Name     Requirement Description
  --------------- ------------- ---------------------------------------------
  NFR-NIST-0001                 

  NFR-NIST-0002                 

  NFR-NIST-0003                 

  NFR-NIST-0004                 

  NFR-NIST-0005                 

  NFR-NIST-0006                 

  NFR-NIST-0007                 

  NFR-NIST-0008                 
  ---------------------------------------------------------------------------

###  {#section-10 .unnumbered}

### Regulatory -- HHS Secure One

  --------------------------------------------------------------------------
  Req ID         Req. Name     Requirement Description
  -------------- ------------- ---------------------------------------------
  NFR-HHS-0001                 

  NFR-HHS-0002                 

  NFR-HHS-0003                 

  NFR-HHS-0004                 

  NFR-HHS-0005                 

  NFR-HHS-0006                 

  NFR-HHS-0007                 

  NFR-HHS-0008                 

  NFR-HHS-0009                 

  NFR-HHS-0010                 
  --------------------------------------------------------------------------

###  {#section-11 .unnumbered}

# Appendix A -- Acronym List {#appendix-a-acronym-list .unnumbered}

This document will use the published glossary for caBIG® found on the
following website: <https://cabig.nci.nih.gov/glossary>.

+-------------+--------------------------------------------------------+
| **Acronym   | **Definition**                                         |
| or Term**   |                                                        |
+=============+========================================================+
| AE          | Adverse Event                                          |
+-------------+--------------------------------------------------------+
| BRIDG       | Biomedical Research Integrated Domain Group (BRIDG)    |
|             | model, a domain analysis model intended to represent   |
|             | the entire domain of preclinical and clinical research |
+-------------+--------------------------------------------------------+
| caBIG®      | Cancer Biomedical Informatics Grid. The acronym given  |
|             | to the project sponsored by the NCI and managed by     |
|             | Booz Allen Hamilton to develop a set of tools for use  |
|             | by the cancer community.                               |
+-------------+--------------------------------------------------------+
| CCTS        | cancer Adverse Event Reporting System. The subject of  |
|             | this document; a system being developed by the         |
|             | SemanticBits for NCI/ caBIG® to capture and report     |
|             | Adverse Events for the cancer clinical trials          |
|             | community                                              |
+-------------+--------------------------------------------------------+
| CDISC       | Clinical Data Interchange Standards Consortium         |
+-------------+--------------------------------------------------------+
| COH         | City of Hope National Medical Center; developer of     |
|             | first release of CCTS                                  |
+-------------+--------------------------------------------------------+
| CRUD        | Create/Read/Update/Delete (CRUD) access                |
|             |                                                        |
|             | Any role requiring restricted access (e.g., LOA2-LOA4) |
|             | must follow NIST guidelines in limiting access to a    |
|             | role.                                                  |
+-------------+--------------------------------------------------------+
| CT          | Clinical Trials.                                       |
+-------------+--------------------------------------------------------+
| CTC         | Common Toxicity Criteria                               |
+-------------+--------------------------------------------------------+
| CTCAE       | Common Terminology Criteria for Adverse Events         |
|             | (replaced "CTC" with the 3^rd^ version of this system) |
+-------------+--------------------------------------------------------+
| CTEP        | Clinical Trials Evaluation Program---a program within  |
|             | the Division of Cancer Treatment and Diagnosis within  |
|             | the NCI.                                               |
+-------------+--------------------------------------------------------+
| CTMS        | Clinical Trials Management System. Often used to refer |
|             | to a computer application developed by a cancer center |
|             | or other entity to record clinical trials data. Also   |
|             | refers to the caBIG® workspace by the same name that   |
|             | is working to develop a comprehensive system for the   |
|             | cancer CT community.                                   |
+-------------+--------------------------------------------------------+
| DCP         | Division of Cancer Prevention                          |
+-------------+--------------------------------------------------------+
| FISMA       | Federal Information Systems Management Act             |
+-------------+--------------------------------------------------------+
| HIPAA       | Health Insurance Portability and Accountability Act:   |
|             | \[per glossary\] federal legislation that gives        |
|             | patients greater access to their own medical records   |
|             | and more control over how their personally             |
|             | identifiable health information is used. The           |
|             | regulation also includes privacy standards that        |
|             | protect patients' medical records and other health     |
|             | information.                                           |
|             |                                                        |
|             | Refer to National Cancer Institute's HIPAA Guidelines  |
|             | for Clinical Imaging Data Sharing for current          |
|             | guidance:                                              |
|             | <https://wiki.nci.nih.g                                |
|             | ov/display/ClinicalImagingDataSharing/HIPAA+guideline> |
|             |                                                        |
|             | Final regulations issued by the Department of Health   |
|             | and Human Services (DHHS) provide privacy and security |
|             | standards that must be observed in the handling of     |
|             | patient data resulting from biomedical research. HIPAA |
|             | privacy standards will be used to establish safeguards |
|             | and restrictions for the use and disclosure of         |
|             | research records. HIPAA security standards will be     |
|             | used to help Cancer Centers implement administrative,  |
|             | physical, and technical safeguards to protect          |
|             | electronic health information. Improper use or         |
|             | disclosure of sensitive information under the rules    |
|             | may be subject to criminal or civil sanctions          |
|             | prescribed in HIPAA.                                   |
+-------------+--------------------------------------------------------+
| [           | Health Level 7: \[per glossary\] a standards           |
| HL7](https: | development organization whose messaging standard is   |
| //cabig.nci | currently the selected standard for the interfacing of |
| .nih.gov/gl | clinical data in most institutions                     |
| ossary/HL7) |                                                        |
+-------------+--------------------------------------------------------+
| IRB         | Institutional Review Board: \[per glossary\] a         |
|             | committee of physicians, statisticians, researchers,   |
|             | community advocates, and others that ensures that a    |
|             | clinical trial is ethical and that the rights of study |
|             | participants are protected.                            |
+-------------+--------------------------------------------------------+
| LOA         | Level of Assurance                                     |
+-------------+--------------------------------------------------------+
| PHI         | Protected Health Information                           |
+-------------+--------------------------------------------------------+
| Privacy     |                                                        |
| Rule        |                                                        |
+-------------+--------------------------------------------------------+
| 21 CFR Part |                                                        |
| 11          |                                                        |
+-------------+--------------------------------------------------------+
| XML         | Extensible Markup Language                             |
+-------------+--------------------------------------------------------+

[^1]: caBIG® Clinical Trials Suite: Software Product Specification,
    Version 1.0, July 27, 2007