ToxDB SOW 2021.11.8.docx

DOCX document 61 KB Posted

Attached to
Toxicology Database (ToxDB) Software Federal contract opportunity
Solicitation number
6973GH-22-R-00023
Issued by
Department of Transportation Federal Aviation Administration Franchise Acquisition Services

About this file

This document outlines a solicitation for a toxicology database software. The Federal Aviation Administration seeks a firm-fixed price contract for a commercial off-the-shelf laboratory information management system software to serve as the Toxicology Database for the Civil Aerospace Medical Institute's Aerospace Medical Research Division. Key requirements include customizable modules and data fields, role-based security meeting FAA standards, ability to share case information across user roles, full auditing, and single case creation. The software must also allow for data aggregation, customizable workflows, workload management, and compliance with federal records retention. The incumbent system is an aging Microsoft Access solution. Offerors must be registered in the System for Award Management by January 24, 2022 to be considered for the contract award. Questions are due by January 3rd and proposals by January 24th. The North American Industry Classification System code is 511210 and the business size standard is $41.5 million.

View the file

Other files for this federal contract opportunity

Other files attached to Toxicology Database (ToxDB) Software, newest first.
File Type Posted
ToxDB Solicitation Questions 2022.1.18_Answered.docx DOCX document
6973GH-22-R-00023 - 0002.pdf PDF
Past Performance Survey 0001.docx DOCX document
6973GH-22-R-00023 0001.pdf PDF
6973GH-22-R-00023 12-15-2021.pdf PDF
Must Checklist- Factor 1.docx DOCX document
Past Performance Experience Form.docx DOCX document
Section B - Supplies or Services-Prices.xlsx XLSX spreadsheet
Client Authorization Letter.docx DOCX document
Past Performance Survey.docx DOCX document

On GovTribe

Work with this file on GovTribe

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Toxicology Database (ToxDB) Software

FEDERAL AVIATION ADMINISTRATION

OFFICE OF AEROSPACE MEDICINE

CONTRACT

For Toxicology Database (ToxDB) Software

STATEMENT OF WORK

November 8, 2021

Prepared by:

Civil Aerospace Medical Institute Office of Aerospace Medicine Federal Aviation Administration Oklahoma City, OK 73125

Contents

1Introduction and Overview3
1.1Background3
1.2Description of the Problem3
2Requirements4
2.1General User Requirements4
2.2ToxDB Technical Requirements5
2.3Information System Security Requirements7
3Documentation8
4Training and Job Performance Aids (JPAs)8
4.1Orientation Training8
4.2Job-Performance Aids8
5Acceptance Test Procedure9
6Government Furnished Property9
7Period of Performance9
8Place of Performance10
9Security10
10Program Management10
11Quality Assurance10
12Communication11
13Invoicing11
14Contract Deliverables11
15Travel11
16Definitions, Acronyms, References:11

1.

Introduction and Overview

i. The purpose of this contract is to provide a firm-fixed price purchase of a Commercial-Off-The-Shelf (COTS) Laboratory Information Management System (LIMS) software to serve as the Toxicology Database (ToxDB) for the Office of Aerospace Medicine’s Civil Aerospace Medical Institute (CAMI) Aerospace Medical Research Division (AAM-600).

0.1 Background

i. This investment is being pursued in support of the CAMI, Bioaeronautical Sciences Research Branch (BSRB, AAM-610) and the Protection and Survival Research Branch (PSRB, AAM-630), of the Federal Aviation Administration (FAA). The BSRB and PSRB assess aircrew health and its relationship to the ability to perform safety sensitive functions through the work of the following teams, each of which uses or maintains the information system that is to be replaced.

a. Forensic Sciences Section (FSS), which develops and utilizes analytical methods to detect the presence of medications, toxins, and other substances that may impact an airman’s in-flight performance.

b. Biomedical Sciences Section (BMS), which houses:

i. The Autopsy Program (AUT) team which supports aviation accident investigations and aeromedical research through the collection, management, and maintenance of autopsy records from fatal aircraft accidents;

ii. Knowledge Management Resource Team (KMRT) which supports the entire Division’s operational and research efforts involving information technology; and

iii. The Functional Genomics (GEN) laboratory which identifies biomarkers pertinent to environmental and other stressors important to aerospace safety.

c. Medical Research Section (MRS) which houses:

i. The Medical Research team, which conducts research into the role of pilot medical conditions in aviation accidents and incidents;

ii. The Medical Case Review Officer, who examines toxicological and autopsy data produced or collected by the BSRB in order to make a determination on the probable cause of aviation accidents.

ii. The data maintained within ToxDB is provided to the National Transportation Safety Board (NTSB), the Federal Aviation Administration (FAA), and researchers involved in projects related to enhancing the safety of the National Airspace (NAS).

0.2 Description of the Problem

i. The BSRB advances aviation safety by providing comprehensive forensic toxicology testing services, cutting edge research in GEN, and top-tier data collection and handling services for civil aviation accidents. The current version of ToxDB has been the long-time data repository for this aviation accident data and includes two applications, ToxFlo and Medical Analysis & Tracking System (MANTRA), that allow access to and processing of the aviation accident data housed in ToxDB.

a. ToxFlo is a laboratory information management system (LIMS) used by FSS personnel for specimen receiving, testing, and chain-of-custody documentation associated with transportation accidents (primarily aviation). ToxFlo includes Personal Identifying Information (PII) data, requiring strict security measures.

b. MANTRA is used by AUT program personnel to coordinate, acquire, store, and maintain data (including investigatory, autopsy, and financial information) related to aircraft accidents. It is also used by the Protection and Survival Research Branch Medical Officers to support the Medical Accident Review and Hazard Analysis Program (MARHAP), which supports the identification, and analysis of aeromedical hazards in fatal accidents.

ii. The current ToxDB solution is an aging system with increasing technical stability issues and security concerns. These are MS Access-based systems, which are less secure than modern web-based applications. The F&E Capital Investment Program, Aerospace Medicine Safety Information System (AMSIS), had originally planned to replace ToxDB during Phase 2 of implementation. However, the Phase 1 of AMSIS is not scheduled for completion until 2024, at the earliest. In addition, funding for Phase 2 is jeopardized by cost overruns in the first phase. ToxDB and its applications are subject to technical issues that pose risks to its long-term viability:

a. ToxFLO and MANTRA are older Access-based programs that are not as secure as modern web-based apps.

b. System updates are not performed on a regular schedule, often requiring the ToxDB applications to be revised in order to remain compatible with other desktop and laboratory systems.

c. The current contract with this single-person vendor expires in 2022. This single point of failure raises risks in regard to health issues, retirement, etc., which would lead to complete loss of service.

iii. Due to these concerns, BSRB personnel explored options for replacing the ToxDB application. It was decided that a COTS LIMS program that could accommodate the specific functions and requirements of both ToxFlo and MANTRA, and the database functionality of ToxDB, would be a workable solution.

1 Requirements

1.1 General User Requirements

i. The product must be web-enabled so that users can easily access it from the internet and/or the FAA intranet.

ii. The system must allow system administration by FAA personnel.

iii. The product must be browser agnostic so that it is fully functional on FAA’s current standard web browser configurations and is adaptable to future changes in web browser technology.

iv. The product must comply with FAA’s standards for Templates and Branding by adding a standard government login screen consistent with other FAA applications. The government will provide the standard text for this login screen.

v. The product must provide full functionality whether being used on a desktop workstation or laptop.

vi. The product must be available and usable 99.5% of the time.

vii. The product must support at least 25 concurrent users.

viii. The vendor must provide the FAA with the most current version of the software, as well as provide system updates as new versions become available.

ix. The vendor must map, migrate, and convert data from the legacy system (Access database based with additional functions written in Visual Basic) into the new system without loss of data integrity.

1.2 Technical Requirements

i. In order for the product to meet the needs of FSS and AUT who use both legacy programs, the product must provide customizable and configurable modules and customizable and configurable fields for data entry.

ii. The product must provide role-based security and meet cybersecurity standards of the FAA.

iii. The product must provide the ability to share case information between different user roles.

iv. The product must provide a full audit trail for all system activity, including but not limited to log-ins, system changes, user information, data entry, and results.

v. The product must provide the ability to create unique alpha-numeric identifiers for each case.

vi. The product must provide any authorized user with the ability to create a case.

vii. The product must provide the ability to create accident cases that include multiple individual accident victims.

viii. The product must provide the ability to perform data aggregation for comparison, benchmarking, and trend analysis.

ix. The product should provide the ability to manage laboratory consumables.

x. The product must provide fully customizable workflow.

xi. The product must provide workload management, including but not limited to, resource availability, specimen tracking, batch production, testing results, QA documentation, reports, and database search functionality.

xii. The product must provide the ability to document case-related information, including, but not limited to, chain of custody, evidence storage and retrieval details, and dates of entry and revision.

xiii. The product should provide a barcoding system for chain of custody.

xiv. The product must provide the ability to store and retrieve electronic images, documents and other file types, including, but not limited to, Microsoft Word, Excel, PDF, JPEG, PNG, SVG.

xv. The product must provide the ability to view and search cases, including the ability to search according to the contents of any included data field, at all times following case creation, including after case closure.

xvi. The product must include the ability to create long text fields with more than 4000 characters.

xvii. The product must provide the ability to run queries for data stored within the system. These queries must be simple to perform for persons without a programming background.

xviii. The product must provide the ability to generate and store specimen inventory templates.

xix. The product must provide a batch analysis function to support the creation of tests for multiple cases or samples.

xx. The product must provide a table to include numerous drugs and the ability for users to add drugs to tables.

xxi. The product must provide control charts to monitor and evaluate quality control samples. This would include blind and open controls material.

xxii. The product must provide the ability to create medical/injury code tables that include descriptions (e.g., ICD-10-CM, CPT, and AIS codes) and associate them to relevant findings. The tables must provide the ability for search capabilities and drop down selection for recurrent use on all cases within the database. These tables must be accessible for use in multiple data fields.

xxiii. The product must provide the ability to create tables for contact information for investigatory personnel. The tables must be editable on all cases.

xxiv. The product must provide the ability to create tables with unique drop-down selections for airman certification, aircraft registry, and related information. The table must have the capability for updating, adding, and deleting the aircraft information.

xxv. The product must provide the ability to generate reports. This must include both built-in standard reports and the ability to create and customize reports ad hoc.

xxvi. The product must provide the ability to export any report in at least, but not limited to, Microsoft Excel or PDF format.

xxvii. As ToxDB is considered a Federal “system of record”, the product must provide the ability to archive records, so personnel can ensure records are appropriately maintained in accordance with Federal record retention regulations. The product must have the ability to auto-create some standardized data collection fields, such as “Date case created”.

xxviii. The product must have the ability to share demographic information for accidents so the end-user does not have to re-enter demographic information. For example, it should have the ability to copy the location, city, state, etc., for mid-air accidents or for multiple victims on a single accident.

xxix. The product must have the ability to interface with other databases on a regular basis and will import desired data.

xxx. The product must have the ability to notify the end user about any fatal accidents that the NTSB has issued the findings of the accident. The findings must be easily viewable to the end-user.

xxxi. The product must have the ability to allow the end-user to copy and paste data into/from the product.

xxxii. The product must have the ability to allow the admin user the ability to delete or modify a case or specific information.

1.3 Information System Security Requirements

i. The product must support installation on a FedRAMP Authorized Cloud instance, using Platform-as-a-Service (PAAS).

ii. The system must account for continuity of operations, so the system is recoverable in the event of a disaster, and so that it complies with FAA/DOT/Government regulations such as NIST 800-53.

iii. The product must support SAML, OATH, or PIV card multi-factor authentication.

iv. The product must provide role-based permissions based on authorization levels (i.e., researcher, support personnel, supervisory medical officer, etc.).

v. The product must comply with the Health Insurance Portability and Accountability Act (HIPAA).

vi. The product must comply with the Privacy Act of 1974.

vii. The product must comply with the FAA’s Information Security and Privacy Program & Policy 1370.121.

viii. The product must comply with Web Content Accessibility Guidelines (WCAG) 2.0 Levels A and AA, in order to meet Department of Transportation (DOT) mandates on accessibility.

ix. The product must show users the standard FAA privacy notice when accessing the system in order to meet FAA/DOT/Government regulations such as DOT Order 1351.33.

x. The product must encrypt all Personally Identifiable Information (PII) in transit and at rest using Advanced Encryption Standard (AES)-256 level encryption, in accordance with FAA/DOT/Government regulations on protecting PII.

xi. The product must use standard FAA access controls, Federal Identity, Credential, and Access Management (FICAM), so user authentication complies with Federal regulations.

xii. The product must follow modern US Government cybersecurity guidelines according to the National Institute of Standards and Technology (NIST) Cybersecurity framework (https://www.nist.gov/cyberframework).

2 Documentation

i. The contractor must supply, in English, the documentation needed to enable CAMI personnel to operate the product. All documentation is to meet best commercial standards.

ii. Agreements concerning documentation must allow a right-to-copy. A documentation review of drafts of all documentation must be held 45 days before final acceptance. Functional draft documentation must be available and will be approved at the time of final acceptance, and the final version of documentation and training materials must be delivered within 60 days after final acceptance.

3 Training and Job Performance Aids (JPAs)

3.1 Orientation Training

i. The contractor must provide on-site orientation training for FAA users of the system. This training must cover general operation of the software. Orientation training must be provided within 30 days after final acceptance of the product.

ii. Instructional aids and materials must be provided to facilitate the learning process and to illustrate special relationships, functions, properties and procedures, and are to be employed during orientation training.

3.2 Job-Performance Aids

i. Job-performance Aids (JPAs) are procedural, highly prescriptive sets of task steps that provide step-by-step guidance to a user in performing a particular task or function. Text and graphics fields must be integrated within a document (either hard copy or computerized) which can be easily used on the job and which can be quickly revised and updated.

ii. To support this activity, the vendor must provide the government with a Data Dictionary, and other assistance such as access to graphics or screen shots, and program documentation regarding software functions, as needed for the Government to create customized JPAs.

4 Acceptance Test Procedure

i. The contractor will demonstrate that all functions perform successfully when accessed by FAA personnel on FAA computing equipment. The contactor will document and demonstrate security functions in a manner acceptable to the FAA Chief Information Officer.

ii. Contractor must provide on-site technical and maintenance support during final acceptance testing.

5 Government Furnished Property

i. After award of the contract, the Government will provide access to existing ToxDB system, including the ToxFlo and MANTRA applications, for data migration. (Details will be described at the post-award conference.)

ii. The Government will not provide/supply the contractor with any other government furnished property or supplies in the performance of this contract.

6 Period of Performance

i. The Contractor must coordinate delivery and installation of the system with the Contracting Officer’s Representative (COR). Contractor must provide on-going system support with appropriate software updates. Customer Support must be available 24/7 telephonically or via email.

ii. The contractor must provide the software, training, documentation and acceptance testing within 180 business days of contract award.

Acquisition Milestones

1.
Post-award kickoff meeting
30 Business Days After Contract Award
2.
Milestone schedule for any modifications necessary to delivery to FAA
60 Business Days After Contract Award
3.
Written acceptance test plan
60 Business Days After Contract Award
4.
Delivery of system to FAA, incorporation of existing records from legacy systems, and user acceptance testing
180 Business Days After Contract Award

7 Place of Performance

i. The Contractor, unless otherwise specified, must provide the deliverables and perform the services for this Contract in the FAA CAMI (5900 S.W. 66th / Building 13) located on the Mike Monroney Aeronautical Center (MMAC) in Oklahoma City, OK. If the contractor is required to be on-site at either location, the contractor’s representatives will be escorted by Federal Government employees at all times and must report to FAA Security with identification.

8 Security

i. The Contractor must coordinate installation of COTS software with the COR in accordance with the statement of work. The Contractor must be escorted throughout the FAA facility when onsite visits are required. During visits, the Contractor must submit to the COR a list of visiting team members by name no later than seven (7) business days prior to scheduled integration for U.S. citizens, or no later than twenty-one (21) days prior to the scheduled integration for foreign nationals.

9 Program Management

i. The Contractor must provide a program manager (PM) to manage the program in accordance with the Statement of Work (SOW) and/or contract requirements. The Contractor must provide the necessary program management including, but not limited to, project management, risk, communications, financial, cost, schedule, and resource management to accomplish the requirements of this SOW.

ii. The Contractor must include, but not be limited to, program management activities such as contract administration, finance, obtaining and retaining qualified personnel, as well as technical support across all phases of the program. The PM must have sufficient corporate resources and authority to direct, execute, and control all elements of the program to ensure efficient and timely program execution. The PM must be the Contractor’s focal point for all required program tasks, including the coordination of all site visits (scheduled and unscheduled). The PM must remain current on related contract activities and be prepared to present and discuss the current program status as well as forecasts related to contract activities with the Government Contracting Officer (CO), the COR, and/or the Government PM.

10 Quality Assurance

i. The Contractor must perform services in accordance with industry standard quality and/or process management practices, for example, ISO 9000, Agile, CMMI, or ITIL.

ii. The Contractor must provide evidence of qualified personnel needed to accomplish the requirements of this SOW by submitting resumes of proposed Contractor team members.

11 Communication

i. Contractor must provide, via contractor’s program manager, status updates every two weeks, including, but not limited to, information on current and projected: technical progress, cost, milestone schedule performance, and action items. Format for this update can be email, PDF, word document, etc., at the discretion of contractor.

12 Invoicing

i. The Contractor must submit invoices in accordance with the contract provisions per service call. Acceptance and payment is contingent upon FAA’s receipt of acceptable service and the respective acceptable invoice. The Contractor must ensure sufficient funding exists on contract prior to providing service.

13 Contract Deliverables

i. Contractor must provide, within 30 days of contract award, a milestone plan, outlining the anticipated dates of their development, test, and delivery milestones to meet the requirements of this SOW.

ii. The contractor must provide documented action items. Open actions must be addressed at each biweekly status update, as described in section 12.

iii. The contractor must provide the hardware (if applicable) and software in addition to any additional material normally provided during the purchase of the software components.

14 Travel

i. The contractor must travel as required to integrate existing data from the legacy systems in coordination with the Government. The contractor’s travel expenses will be reimbursed expenses in accordance with the Federal Travel Regulations.

15 Definitions, Acronyms, References:

As used throughout this contract, the following terms have the meaning set forth below and specified as applicable:

i. General Definitions

a. Aerospace Medicine – FAA organization responsible for medical certification, research, education, and occupational health in order to enhance aviation safety.

b. Aviation Safety (AVS) Quality Management System (QMS) – AVS is committed to continuously improving the world's safest aerospace system. AVS fulfills this commitment by responding to our stakeholders, supporting the interests of the flying public, valuing the contributions of each employee, and meeting the requirements of the AVS quality management system. (https://employees.faa.gov/org/linebusiness/avs/programs/qms/)

c. Configurable – Is the process of using native tools in a software system to change the behavior or features to meet the business model.

d. Contractor/vendor - These terms, used interchangeably, refer to the prime Contractor. The prime Contractor must provide a single point of contact (an employee of the prime) to coordinate all tasking, schedules, and requirements. The contractor must ensure that his/her subcontracts (if any) comply with the provisions of this contract.

e. Contracting Officer (CO) - One with authority to enter into, administer, and/or terminate contracts and make related determinations.

f. Contracting Officer Representative (COR) - The Contracting Officer (CO) may delegate a representative in writing who will coordinate with the contractor for performance of services outlined in the SOW. The Contracting Officer’s Representative (COR) does not possess authority to change the provisions of terms of the contract, or otherwise commit the Government. The COR is not authorized to make changes that affect cost or change the scope. The CO is the only individual authorized to make these changes.

g. Conversion – Is the process of converting computer data from one format to another.

h. Customizable – Is the process of designing, creating, deploying, tailoring and maintaining software for a specific set of users or functions.

i. Government Owned Property (GOP) - All property owned by or leased to the Government or acquired by the Government under the terms of the contract. Government property included both Government furnished property and Contract acquired property as defined in AMS Guidance T3.10.3.

j. Health professionals – Doctors, nurses, physician assistants, nurse practitioners, and health technicians, other staff who provide medical care / services to patients.

k. Mapping – Is the process of creating data element equivalence mappings between two distinct software

l. Migration – Is the process of selecting, preparing, extracting, transforming data and importing from one software to another.

m. Quality Control (QC) – Those Actions taken by the Contractor to ensure system performance meets the requirements of the SOW.

ii. Acronyms

a. (AAM) Office of Aerospace Medicine

b. (AES) Advanced Encryption Standard

c. (AMSIS) Aerospace Medicine Safety Information System

d. (API) Application Programming Interface

e. (AVS) Aviation Safety

f. (CAMI) Civil Aerospace Medical Institute

g. (CDC) Centers for Disease Control and Prevention

h. (CLIA) Clinical Laboratory Improvement Amendments

i. (CO) Contracting Officer

j. (COR) Contracting Officer Representative

k. (COTS/NDI) Commercial-Off-the-Shelf/Non-development Item

l. (DOT) Department of Transportation

m. (EPA) Environmental Protection Agency

n. (FAA) Federal Aviation Administration

o. (GOP) Government Owned Property

p. (HIPAA) Health Insurance Portability nd Accountability Act

q. (HQ) Headquarters (located in Washington, DC)(IAAS) Infrastructure as a Service

r. (ISO) International Organization for Standardization

s. (JPA) Job Performance Aids

t. (MARHAP) Medical Accident Review and Hazard Analysis Program

u. (NIST) National Institute of Standards and Technology

v. (OATH) the Initiative for Open Authentication

w. (OHSA) Occupational Safety and Health Administration

x. (PA) Privacy Act of 1974, amended January12, 2018

y. (PII) Personally Identifiable Information

z. (PHI) Protected Health Information

aa. (PIV) Personal Identity Verification

ab. (PM) Program Manager

ac. (QC) Quality Control

ad. (QMS) Quality Management System

ae. (SAML) Security Assertion Markup Language

af. (SAAS) Software as a Service

ag. (SOW) Statement of Work

ah. (WCAG) Web Content Accessibility Guidelines

File details come from the government source that posted it. Updated .