NB112000-16-05281_IRB_FUNCTIONAL_ _TECHNICAL_REQUIREMENTS_7-29-2016.doc

FUNCTIONAL AND TECHNICAL REQUIREMENTS FOR IRB SOFTWARE

Functional Requirements

The software solution shall minimally:

· offer a central portal for the user to access all modules from one online access point

· support role-based user permissions

· support multiple roles per user and allow for creation of custom roles with custom privileges

· offer customizable views based on user's system role

· offer a consistent and intuitive look, feel, logic, and navigation throughout all modules

· offer electronic forms with branching capabilities (smart forms) to accommodate business processes

· offer a smart form starter template that can be easily modified by HSPO administrative staff

· allow admin to perform non-code altering updates (e.g. modify value lists for form controls, etc.)

· allow different research team members to complete different sections of the smart form

· offer help functionality

· offer spell check and auto-save functionality

· allow users to clone a prior submission to start a new submission

· allow grouping information for each protocol together (such as including new application, amendments, revisions, unanticipated problems/adverse events, and renewals of approval)

· provide the ability to create and manage email communications with ability for administrator to directly embed database elements into email template

· provide email functionality including but not limited to:

· triggers for auto-notification (logic = by date, submission type, action type, action overdue, status change, etc.)

· manual (non-template) email functionality

· emails based on specific reminder frequencies

· notify users via NIST email account that action has occurred or is required

· capture responses from NIST email in software

· allow admin staff to create email lists for group emails. (e.g. a specific news bulletin to research staff involved in a study)

· provide electronic review and approval routing

· be able to halt workflow if specific requirements are not met (e.g. missing attachments, training requirements)

· allow users to attach files (e.g. Word, PDF, audio, video) to submissions (e.g. informed consent documents, SOPs, recruitment flyers, etc.)

· provide "tum-around-time" reporting that can identify bottlenecks in workflow (e.g. submissions that are taking a long time to process, a PI that is not responding to stipulations, etc.)

· provide robust query functionality to allow the user to create ad-hoc queries and reports based on any data field(s) or combination of fields across different modules based on user permissions

· provide importing of completed training data from Citi (www.citiprogram.org)

· provide the ability to save an ad-hoc query for future use

· provide the following reporting functionality:

· parameter-based reports (e.g., comma-separated values)

· user selected output format including PDF, Word, Excel, CSV

· 21 CFR Part 11 signatory compliance ("Secure, computer-generated, time-stamped audit trails for (operator entries and actions) to electronic records which shall not obscure previously recorded information")

· standard accreditation and regulatory reports

· auto generate unique ID fields for every record & have the ability to add custom prefix and suffix and different combination of letters & numbers

· provide field validation within smart forms including:

· required fields

· validation of data type (e.g. alpha vs. numeric)

· allow administrator to set validation criteria

· allow authorized user to print protocol

· allow user to print all current files associated with an entire approved protocol at one time

· allow user to print completed smart forms without the instructions from the screen version of the form

· allow the user to enter unique data a single time and have it auto-populated across all modules

· support full data integration between modules

· provide a standard IRB application module (pre-configured "out of the box" with the ability to customize it)

· allow user to create an initial IRB application online using a smart form or dynamic questionnaire that guides user to answer questions that are specific to their study type and detail

· allow the user to create an initial application over time including but not limited to the following functions:

· edit saved drafts

· delete saved drafts

· clone/copy previously created application

· allow the user to to track changes in protocols as they are revised, so that changes are highlighted or marked for reviewers

· provide user with submission checklists that guide user and ensure that all necessary information, attachments, etc. have been included

· allow user to view the current status for all of their submissions (e.g., initial application, change requests)

· allow user to view auditable submission history throughout study lifecycle (both pre- and post-approval)

· allow user to modify information on submitted but pre-approved application

· allow the user to submit the application online

· the solution should allow other authorized users listed on the application to view or edit based on privileges

· allow admin staff and committee members to view comments and stipulations by other committee/staff members (both pre-and post-approval)

· allow users to respond to admin staff comments and/or committee stipulations

· allow admin staff to pre-review and modify submitted applications

· allow admin staff to create review committees

· allow admin staff to modify review committees (e.g., alter membership, roles, and permissions)

· allow admin staff to specify review type for each application (e.g., determine if application should be routed for full committee review, expedited review, exempt, or not human subjects research)

· allow admin staff to specify determination type for each application (e.g., researcher, not human subjects research or human subjects research determination)

· allow admin staff to complete institutional engagement determination

· allow admin staff to complete institutional review of non-NIST IRB approved research protocols

· allow admin staff to assign reviewer(s) for each application

· allow admin staff to assign multiple roles to a committee member

· allow reviewer comments to be compiled in a "study-specific reviewer comments" report to be used at committee meetings

· allow committee members to view agenda online

· allow admin staff to send application and supporting documents/attachments to committee members electronically for review (e.g., MS Word, PDF)

· allow admin staff to build committee meetings, including but not limited to:

· assign primary reviewers, secondary reviewers and expert reviewers

· specify meeting date

· email meeting invite to reviewers/committee

· create agenda (specify and/or auto-generate)

· assign agenda

· email agenda to committee

· print meeting agenda (as PDF, MS Word)

· allow admin staff to capture and manage committee meeting minutes

· allow admin staff to generate routine correspondence to users (e.g., modifications required letters, approval letters, etc.)

· allow user to view/print study approval letter

· allow user to create and submit online Continuing Review and Amendment request utilizing a smart form

· allow user to create and submit online Adverse Events notification using smart form

· allow user to close approved study (post-approval)

· allow admin staff to keep records for the length of time that meets federal standards (three years), and provide the feature to allow old records to be maintained and/or archived

· allow admin staff to maintain a library of files for reference by users

· Optional: an ability to import existing data (e.g., PDF, MS Word, Excel) from current proposal management current process.

Technical Requirements

IT Security. The Contractor shall demonstrate that all of its components and controls within the system boundary* is compliant with the Federal Information Processing Standards (FIPS) Publication 200, ‘Minimum Security Requirements for Federal Information and Information Systems’ and NIST Special Publication 800-53 ‘Security and Privacy Controls for Federal Information Systems and Organizations,’ at the moderate impact level. Acceptable evidence of compliance may include the following: FedRAMP authorization, an Authorization to Operate (ATO) letter issued by a Federal Government agency as evidence that they have been assessed and authorized at the moderate impact level (the Contractor must be able to provide NIST the capability of reviewing the full package from that agency), or that they have passed an independent security audit (e.g., Statement on Standards for Attestation Engagements (SSAE), PCI Data Security Standard (PCI DSS), etc.).

*The system boundary must include all Contractors and sub-Contractors that transmit, store, access or can access NIST data. NIST must approve system boundaries.

Post contract award, the Government will perform a review for a local ATO decision, required for go-live, and ongoing security assessments for continuous monitoring thereafter. The Government will determine the risk rating of identified vulnerabilities. The Contractor shall respond to the Government with an action plan and schedule to mitigate security risks found within 10 business days of notification of security risks. The Government will notify the Contractor of whether or not the action plan and schedule are acceptable. The Contractor shall implement the action plan according to the agreed-upon schedule.

Anticipated impact rating levels based on NIST use cases (by security objective) are Confidentiality = Moderate, Integrity = Moderate, and Availability = Low.

Internet Protocol Version 6 (IPv6). The Contractor services shall be accessible through both Internet Protocol Version 6 (IPv6) and IPv4. If not already compliant, the Contractor shall provide the Government with a statement regarding its plans to implement IPv6, including timeframe.

Trusted Internet Connections (TIC). The Contractor shall provide the ability to restrict government access to the cloud service from government specified networks, in accordance with the Office of Management and Budget (OMB) Memorandum M-08-05, “Implementation of Trusted Internet Connections (TIC),” and the Department of Homeland Security’s “Trusted Internet Connections (TIC) Reference Architecture Document Version 2.0.” If not currently able to provide this ability, the Contractor shall provide the Government with a statement regarding its plans to have such capability, including timeframe.

Section 508. The Contractor shall create and maintain a system that complies with Section 508 of the Rehabilitation Act.

Authentication. The Contractor shall configure its system or application to be compliant with:

· Homeland Security Presidential Directive 12 (HSPD-12): Policy for a Common Identification Standard for Federal Employees and Contractors.

· National Strategy for Trusted Identities in Cyberspace (NSTIC)

The preferred user authentication methods are through integration with Connect.gov and application issued credentials. Connect.gov can provide both PIV card and approved third party credentials. Users shall be given the option of using an acceptable PIV, third party credential or establishing a credential with the Contractor provided solution. Applications that cannot integrate with Connect.gov will implement user authentication via Government issued PIV cards, approved third party credentials and Contractor solution-provided credentials. Third party authentication must be consistent with NSTIC; with providers and protocols approved by the Federal Identity, Credential, and Access Management (FICAM) Trust Framework Solutions (TFS) Program. In all cases a Contractor solution-provided credential must also be supported to allow access by external collaborators that do not have or do not wish to use a trusted third party credential. All credentials shall be consistent with NIST Special Publication 800-63, Electronic Authentication Guideline, and the system’s accessed Level of Assurance (LOA). The required minimal LOA is Level 2.

Incident Response. The Contractor shall be able to provide to NIST the qualifications and contact information of their security and incident response team. The Contractor shall notify NIST within three (3) hours of any possible malicious activity, providing a unique incident reference number and contact information for further details. The Contractor shall provide any application and operating system logs associated with an incident as well as a file system timeline for potentially compromised hosts and any additional files referenced during forensic analysis upon request. If possible the Contractor shall provide memory dumps and forensic images of any NIST systems that were possibly compromised.

Other Requirements (functionality):

· provide integration via application programming interfaces (APl) and/or Web Services to support communication across platforms and programming languages

· support major browsers, specifically IE, Safari, and Chrome

· support access from portable laptop/devices/tablets/smart phones

· be highly scalable to support increase in users and traffic

· be compatible on both Windows and Macintosh OS X operating system