Attachment 1 FMRIF Database SOW.pdf

Version 11-30-2016-1 FAR Part 11—Describing Agency Needs

STATEMENT OF WORK (SERVICES)

(SOW)

GENERAL INFORMATION

Title of Project:

Functional MRI scientific data management system for FMRIF.

Statement of Need and Purpose:

The Functional MRI Facility (FMRIF) in the National Institute of Mental Health (NIMH) is seeking a data and workflow management platform. This platform will aggregate data from the MRI scanners that the

FMRIF operates, provides access to these data to FMRIF users, and will also serve as a platform for both sharing and managing these data in the future.

Background Information and Objective:

Since its inception, FMRIF has operated a series of web-based platforms that serve to both aggregate image data from the MRI scanners owned and operated by the FMRIF, and to share these data out to its users, so they could securely retrieve their data using a web browser, or other web-based tools. The first such service used by FMRIF was a commercial PACS system from Intelerad. However, as both the number of scans conducted on FMRIF scanners rose, along with the volume of Functional MRI data generated, FMRIF encountered significant performance issues that could not be resolved by the vendor of that system. FMRIF then investigated multiple options to replace the Intelerad system, exploring both commercial and open source software (including, but not limited to, dcm4chee, XNAT, COINS, and

NiDB). In all cases, there were either significant deficiencies, and / or lack of flexibility, that precluded use of any of these packages by FMRIF. Ultimately, a custom database and web application was created in-house, by a FMRIF-employed programmer. This platform has served us well for most of the last decade.

However, now – this platform is beginning to show its limits, both in terms of being able to integrate with new IT requirements, and new software tools and processing tools. FMRIF is therefore seeking to modernize and update its platform for capturing, aggregating, processing, and sharing its Functional MRI data, and that is the aim of this requisition.

Period of Performance:

The period of performance is 12 months from date of award, plus one, 12-month option year.

Base Year: (Months 0- 12) Option year 1: (Months 13 - 24)

Option year 2: (Months 25 - 36)

Option year 3: (Months 37 - 48)

Option year 4: (Months 49 - 60)

Installation and deployment is expected to happen 90 – 270 days after receipt of order. Options to continue support and service for an additional 4 years after the initial year are desired.

SCOPE OF WORK

General Requirements:

Independently and not as an agent of the Government, the Contractor shall furnish all the necessary services, qualified personnel, material, equipment, and facilities, not otherwise provided by the

Government as needed to perform the Statement of Work below:

Specific Requirements:

The chosen platform must be able to:

• Interface with multiple MR scanner vendors, and automatically capture and aggregate both raw (k-space) and DICOM data generated by these vendors’ platforms.

• Transport acquired and computed DICOM data between (i.e. send to and receive from) the platform and commercial PACS systems, and MR scanners

• Integrate with institutional authentication system (LDAP and Active Directory) for user authentication and system access.

• Be installed on local (on-premises) hardware or virtual system, and offer remote management capabilities by contractor.

• Provide interfaces for managing users’ access to data (i.e. assigning role-based privileges set at the project level, e.g. admin, read/write, read-only, and use groups to organize users into labs, teams, for example).

• Comprehensively log all user and job activity when using the database.

• Provide training and training materials for FMRIF staff to administer and use the system, as well as allowing FMRIF staff to train its own users on how to work with this system.

• Provide interfaces to locate captured DICOM data, organized according to project, scan date or session, data types, etc.

• Allow users to readily download “original” data from the system, i.e. data that have not been processed by the system in any manner, except for aggregation into sessions, studies, and projects, and generation of lossless archival format (for example, but not limited to, ZIP, tar + gzip, or similar technologies) files.

• Provide tools for version tracking and maintaining provenance of data and analysis pipelines.

• Load FMRIF’s retrospective data, estimated to include roughly 70,000 MRI exams into the new database.

• Manage and process Functional MRI data series, with each series having tens of thousands (and soon to reach hundreds of thousands) of images. System must be able to process and appropriately aggregate and make available to users up to 250 such series every 24 hours with the initial deployment.

• Scale compute and storage needs as the number of scanners, aggregated studies, and data processing compute load increase.

• Provide tools and / or interfaces to aggregate other data streams (for example, but not limited to – physiological data) with imaging data.

• Provide interfaces for visualizing and analyzing data, including, but not limited to, derivation of basic quality assurance metrics.

• Provides tools and / or interfaces for metadata search and management.

• Provide tools to leverage OCI-compliant containers for data processing, including, but not limited to, containers providing tools such as AFNI, FreeSurfer, and FSL.

• Interface with large-scale batch processing system such as slurm and PBS on local HPC and commercial cloud compute resources.

• Export image and study data into BIDS (Brain Imaging Data Structure) compliant data sets.

• Provide automated and customizable data anonymization / de-identification for exported datasets.

• Provide open REST-based APIs to all services and data, and support for external language SDKs (e.g. MATLAB, Python, and R).

• Provide command line integration access to API to facilitate scripting, data import and export, job scheduling and status, and building analysis pipelines.

• Demonstrate the performance of the system on a sample dataset to be provided by the customer.

The demonstration will include importing of the customer's dataset into the offeror's system, performing a series of quality assurance tests on the data, and reporting the results from those tests to the customer, in a live session.

• Provide guaranteed response times to customer queries about issues, acknowledging of receipt of report of issues within 24 hours, with a 4 week window to resolving any issues raised.

• Provide mechanisms and interfaces for validation of data uploads into the system, and detection and logging of errors or omissions with such uploads.

LEVEL OF EFFORT:

The contractor is expected to employ staff familiar with DICOM communication protocols, understand various computer network communication protocols and security standards, and also familiar with medical imaging data processing requirements.

GOVERNMENT RESPONSIBILITIES:

The government will supply all information necessary for contractor to complete their efforts. The government will also provide either physical or virtual computer systems on which the software platform will be deployed. Under a Memorandum of Understanding (MOU) between the contractor and government, the government will also provide remote access to vendor to system(s) on which the platform is deployed, to facilitate trouble-shooting, and performance and feature enhancements.

DELIVERY OR DELIVERABLES:

The contractor must deploy the scientific imaging data management system to a FMRIF-operated physical or virtual computers, and demonstrate how its operations meets and conforms to the above-listed “Specific Requirements.” Installation and deployment is expected to happen 90 – 270 days after receipt of order.

The contractor must also help maintain the performance of the system, as well its adherence to all security policies and requirements.

REPORTING REQUIREMENTS:

The contractor should report general performance metrics of the platform (relative compute load, and storage usage), at a minimum, on a bi-weekly basis. The contractor should also report when systems are accessed, and for what purposes was access made. The contractor should also notify when system patches and updates become available, to enhance performance of the platform, as well as satisfy security and policy requirements.

OTHER CONSIDERATIONS:

Travel:

Travel may be required in the performance of the SOW at the start of this project. It is estimated that up to three trips may be required for installation and deployment. After setup, all support is expected to be done remotely. Any and all travel costs are expected to be covered by the costs of this contract.

Key Personnel:

The relevant key personnel have been specified under the “Level of Effort” section.

Information System Security Plan:

This statement of work requires the contractor to (1) develop, (2) have the ability to access, and (3) maintain a federal information system. All work on this platform, and access to the machines on it will be under a Memorandum of Understanding between the contract and NIH’s Center for Information

Technology. Contractor will maintain systems to provide best performance, and also maintain compliance with current NIH policies and requirements.

Data Rights:

Any data generated by this procurement or system will belong to the Government. The Government will retain all rights over any generated data.

Section 508—Electronic and Information Technology Standards:

The contractor shall comply with Section 508 of the Rehabilitation Act (29 U.S.C. § 794d), as amended by the Workforce Investment Act of 1998 (P.L. 105-220), August 7, 1998. This system will not be accessible to the general public – it will only be accessible NIH employees with the relevant training.

Publications and Publicity:

This SOW is not expected to generate any publications.

Confidentiality of Information:

This SOW is not expected to utilize or generate any confidential information.