RFQAttachmentNo.1SIPSSOWandTerms.pdf

FDA-RFQ-18-1196672 Page 1 of 67 RFQ Attachment No. 1: FDA’s Safety and Inventory Protocol System (SIPS) Statement of Work

Title: IT Lifecycle Support for FDA’s Safety Inventory and Protocol System (SIPS) and Nexus COTs 4x License Renewal or Equivalent

1 Background Since 2014, the US Food and Drug Administration (FDA) has been working to consolidate many of its administrative and research activities at the Federal Research Center, White Oak campus and other FDA locations. With the physical relocation to the White Oak campus, the Office of the Commissioner, Center for Drug Evaluation and Research, Center for Devices and Radiological Health and the Center for Biological Evaluation and Research determined that one entity would serve as the provider of all the Occupational Safety and Health needs for the campus. In response to this determination, the Safety Inventory and Protocol program was established to implement coordinated program efforts in the following (8) functional areas:

• Radiation Safety

• Chemical Safety

• Biological Safety

• Laboratory Safety and Compliance

• Animal Inventory

• Employee Medical Record/Medical Surveillance Manager (EMR/MSM) Occupational

Health and Safety (OHS)

• Workplace Incidents Management

• Research Involving Human Subjects Internal Review Board (IRB).

Safety Inventory and Protocol System (SIPS) is FDA’s primary repository for storing safety researcher registrations and researcher safety protocol listing data across the FDA. SIPS tracks incidents within agency locations; tracks chemical, biological, and radiological research protocols; and tracks employee health and medical records. SIPS supports the following business needs:

• Internal Review Board (IRB) Protocol Registration

• Health Physics Assistance (Radiation Safety Database)

• Chemical Safety Assistance (The Environmental protection data systems Chemical Inventory System)

• Biological Safety Assistance

• Compliance Assistance (Lab Safety)

• Animal & Inventory Assistance

• Accidental & Injury Assistance

• Occupational Heath Assistance

SIPs assists FDA’s Employee Safety and Environment Management (ESEM) staff within the Office of Commissioner (OC), manage integrated Occupational Safety and Health programs for the

FDA-RFQ-18-1196672 Page 2 of 67 entire agency. Programs supported include Occupational Medicine, Radiation Safety, Biological Safety, Environmental Protection, Chemical Inventory, and Occupational Safety and Health regulations.

SIPS is hosted at the FDA and the framework is currently based on a HealthRx’s Nexus COTS 4.x.

The Nexus COTs product has been configured and customized to meet laboratory safety and occupation health requirements for FDA. The application and database reside on dedicated servers that conform to the FDA Enterprise Architecture (EA) standard for software products and the “ICT21” Technical Reference Architecture standards. This architecture includes a shared SQL database instance and dedicated instance for the application servers. SIPS also interfaces with other Agency systems such as the PingFederate server, and Enterprise Administrative Support Environment (EASE).

Currently, majority of the administrative and research polices, records of regulation compliance, researcher registrations, researcher protocols, processes (user workflows), and safety protocol reports, are either in paper form, not integrated across the FDA, or non-existent. The SIPS programs efforts of formalizing and automating began a transformation for environmental safety across FDA White Oak campus and other locations.

2 TECHNICAL ENVIORNMENT

FDA’S DATA CENTERS AND SERVER ENVIRONMENTS

The contractor shall support Nexus Licenses or equivalent on FDA’s technical environment.

FDA’s Technical Environment is comprised of the following:

White Oak Infrastructure Architecture (WODC) Each of the WODC Presentation, Application, and Data Zones, as well as their supporting enclaves, has the following characteristics: Core/Distribution infrastructure support that includes dedicated, redundant firewalls, switches, and optional load balancers, except for the Data Zone, to ensure consistent and scalable infrastructure services for applications that are deployed into each Zone. The contractor will work with the virtual server environments to ensure accommodation of their individual configuration and access needs Common server hardware support wherever possible for each application deployment in the Zone enclaves.

Development Environment The Development Environment provides’ the Development Team with a stable working environment with maximum privileges, and is being used to perform the unit testing of code.

The servers for this environment are available in a virtual environment in a contractor supported data center at the FDA White Oak, MD campus. This is the only environment that permits development activities. SIPS business sponsor, the Office of Laboratory Science and Safety (OLSS), anticipates enhancements that may add to or modify the COTS code to meet the individual Project Management / Workflow needs of FDA offices interfacing with OLSS.

Test Environment The Test Environment maintains a stable environment to conduct testing including integration testing which allows frequent refresh of data or the code baseline if necessary. The Test Environment is available on a virtual environment in a hosted data center at the FDA White Oak, FDA-RFQ-18-1196672 Page 3 of 67

MD campus and is configured as closely as possible to match the Pre-Production Environment. This environment allows for load testing, integration testing as part of the approval process for code release. The Test environment is anticipated to be used to conduct enhancements and defects verification that may add to or modify the COTS code to meet the individual Project Management / Workflow needs of FDA offices.

CHDC Infrastructure Architecture (CHDC) The Contractor Hosted Data Center, also known as the Ashburn Data Center (ADC), provides support for the FDA’s main Production and Pre-Production environments. Upon approval and authorized configuration of the selected software tool, OLSS anticipates the contractor will primarily be working within the pre-production and production environments at CHDC. The CHDC and WODC data centers adhere to the same multi-zone architecture and are scaled per their specific computing requirements.

Pre-Production Environment

The Pre-Production environment is on a physical server and will be available to contractors on virtual servers in a cloud configuration in a hosted data center in Ashburn, VA and is configured as closely as possible to match the Production Environment. User Acceptance Testing (UAT) and Performance Testing take place in the Pre-Production environment. The end users will designate a team of UAT user accounts that are maintained in this environment.

Production Environment

The Production environment is on a physical server and will be available to contractors on virtual servers in a cloud configuration in a hosted data center in Ashburn, VA.

Current State of the SIPS Software Environment The following illustrates the SIPS technical environment as it is today. The SIPS has been transferred to FDA infrastructure from contractor hosted location at the beginning of September 2017.

2.1 Current-State Diagram

FDA-RFQ-18-1196672 Page 4 of 67

3 IT CONSTRAINTS

This Statement of Work (SOW) requires the contractor to (1) develop, (2) have the ability to access, or (3) host and/or maintain a Federal information system(s). Pursuant to Federal and Department of Human and Health Services (HHS) Information Security Program Policies, the contractor and any subcontractor performing under this task order shall comply with the following requirements:

FDA Enterprise Performance Life Cycle (EPLC) The contractor shall follow FDA’s Enterprise Performance Life Cycle (EPLC) framework for all software O&M and DME activities. The EPLC framework provides a standard structure for planning, managing and overseeing IT projects over their entire life cycle. FDA’s Office of Information Management (OIM) follows the FDA’s EPLC. The EPLC framework consists of ten life cycle phases. Within each phase, activities, responsibilities, reviews, and deliverables are defined. Exit criteria are established for each phase, and Stage Gate reviews are conducted through the IT governance process to ensure that the project’s management quality, soundness, and technical feasibility remain adequate and the project is ready to move forward to the next phase. The EPLC framework provides a guide to Project Managers, Business Owners, IT Governance Executives, other Stakeholders, and Critical Partners throughout the life of the project (See RFQ Attachment No. 3 – EPLC Artifacts for more detail on FDA’s EPLC Processes).

Federal Information Security Management Act (FISMA) The Contractor shall coordinate with the FDA appointed Information System Security Officer (ISSO) to maintain regarding all software and software related processes. This may include physical security access controls.

FDA-RFQ-18-1196672 Page 5 of 67

FDA Master Approved Technologies List - The FDA Master Approved Technology (MAT) List contains a list of approved and not approved technologies including applications (software), infrastructure and peripherals (hardware), and scientific software and devices.

Request Quality Services and Technology from IT (RQST-IT Tracker) FDA has instituted the RQST-IT process in order to track technologies across the agency. The introduction of a new technology or a different version of an already approved technology requires the submission and approval of an RQST-IT request. The Contractor shall be responsible for supporting the RQST-IT process including writing and submitting requests and tracking them from inception through completion. FDA Center IT Investment Review Boards (ITIRBs) may need to be included in a coordinated review process. The RQST-IT process is also used to request the provisioning of new servers in both data centers.

Configuration Management: The contractor shall adhere to and utilize configuration management procedures approved by the FDA COR. The Contractor shall work with FDA configuration management support staff to utilize existing configuration management practices and tools.

I Change Control: The contractor shall follow the established procedures of the formal SIPS Change Management (CM) Plan. The SIPS CM process is an approach that includes the Configuration Control Board (CCB) which is responsible for processing change requests (CRs) that are within scope, schedule, and budget, and includes Office of Information Management Technology, Office of Enterprise Program senior level management body that determines the direction of requests that are out of scope and would impact cost and schedule baselines. The contractor will provide an impact, alternatives, and level of effort estimates and times needed for completion of all CRs in accordance with the CM Plan. The CM Plan and CCB Charter will be provided as Government Furnished Information.

Release Management: The contractor shall practice version control of all critical project documents, all applications, and database components. The Contractor shall use tools approved by the Architecture Review Team (ART) of the FDA.

Stage Gate Review (SGR) Support SGRs are FDA’s release review and approval process, which focuses on the review and approval of the EPLC documents created or modified per the Project Process Agreement (PPA) for the release. The Contractor shall provide the Government with the technical support to create or modify documents per the PPA. The Contractor shall be available to attend the SGR upon notification of the COR.

Puppet Auto-Deployment The Contractor shall use Puppet auto-deployment process (a software upgrade release system already in production at FDA) to deploy all releases, after the first initial implementation, including: maintenance, enhancement and emergency releases, for Pre-Production and Production environments, where available. The Contractor shall provide Self Service Automated Application Deployments in Test environment. The Application Deployment Artifacts shall be

FDA-RFQ-18-1196672 Page 6 of 67 tested in the Test environment and then provided to FDA IT Server administrators for both WODC & ADC that will auto install these upgrades/releases in (Pre-Prod/Prod).

4 Objectives The objective of this contract is to renew Nexus COTS v.4.x Enterprise license suite or equivalent products, obtain Information Technology (IT) Lifecycle Support Services for SIPS, and support FDA’s public health mission by:

• Achieving compliance with the Federal, state and local environment, safety and health (ESH) laws and regulations and other applicable requirements.

• Establishing meaningful and measurable targets and objectives; reviewing our performance; providing oversight; and implementing corrective actions whenever necessary.

• Clearly and openly considering safety and health impacts, risks and other factors in relevant operations and decisions.

• Creating a workplace culture of safety by having leaders, supervisors and managers communicating clear expectations; facilitating active employee involvement through delegation, and resource allocation; and managing performance and communications.

• Expecting active employee participation throughout the Agency and promoting an ongoing dialogue with stakeholders to encourage innovation for continual improvement.

5 Scope of Work The scope of this work includes:

Renewing annual Nexus COTS 4.x enterprise licenses or equivalent. The Enterprise licenses currently supports 23,000 users and must be made available to all FDA PIV enabled badge employees if the number users increase above 23,000 over the life of this contract.

Obtaining full IT Lifecycle Support for SIPS that is currently available to end users and hosted on dedicated servers in FDA’s production environment. This includes Operations and Maintenance Support, Training; Project Management; Release Management; Data Analytics and Reporting;

and Development, Modernization and Enhancements of the following modules:

The Radiation Safety module, PI Dashboard, implemented in 2017, performs two essential functions: it provides a complete lifecycle accounting of the operational parameters of the radiation safety program for management oversight, and; provides critical evidence of compliance with the licensing regulations of the Nuclear Regulatory Commission and any other occupational or environmental regulations.

The Chemical Safety/Inventory module, implemented in 2017, supports the FDA chemical inventory. This module allows for hand bar-coding of bottled chemicals when received and removed from the FDA. When bottled chemicals are depleted, the module provides the totals of hazardous and flammable chemicals for the individual floors of laboratory buildings that could be used in emergency response situations. As well, this

FDA-RFQ-18-1196672 Page 7 of 67 module ensures that regulatory limits are not exceeded. The chemical inventory module complies with numerous Federal and State regulations. It interfaces with PI-Dashboard on different registration types such as radiological, chemical and human subjects and biological for inventory management. FDA requires to de-activate Animal PI-Dashboard and its interface with Inventory module.

The Biological Safety module, PI Dashboard, implemented in 2017, records, maintains, and reports information to support ongoing laboratory activities. This includes personnel location and suitability- certifications, permits, required training, vaccination status, and equipment ratings relevant for personnel working in Biosafety levels I, II, and III. In addition, the biological module tracks equipment, consumables, cradle-to-grave laboratory specimens, and test animals related to ongoing research activities onsite, based on building/laboratory. The laboratory specimens included in tracking laboratory specimens includes select agents, from delivery/assignment to a principal investigator through destruction/disposal. The Biological Safety module also tracks maintenance service, repair service calls, and operations history for laboratory equipment, and quantities/usage of laboratory consumables (reagents, preparation supplies, etc). The Biological Safety module also records and maintains version control for all laboratory and safety protocols, consistent with Biosafety in Microbiological and Biomedical Laboratories, 5th Ed. (BMBL) requirements for Biosafety levels I, II, and III.

The Laboratory Safety and Compliance module, surfaces all active laboratory space, protocols and materials to EHS to drive lab inspections and compliance. Enables view of research activity multiple ways including by floor, lab, PI, associated researcher, safety inspector, and material. Initiate a lab inspection by selecting pre-defined forms appropriate to work being done in lab, quickly conduct inspection, checking off deficiencies and adding notes documents, and pictures, manage resolution of deficiencies, and issue final inspection report. Data is used to produce many compliance and tracking reports.

The Employee Medical Record/Medical Surveillance Manager (EMR/MSM) module, for Occupational Health and Safety (OHS), has been fully operational since September 2017, and is a medical surveillance module specifically designed to help protect employees from nontraditional risks. The EMR/MSM was configured to support various styles of medical practice and includes specialized Occupational Medicine templates. This module allows an FDA’s Occupational Medical Service clinic to recall patients into the clinic for surveillance appointments based on workplace risks. The Clinical Access Manager (CAM) in this module is a tool for patient and provider scheduling, automatic charge capture, and analysis of utilization and outcomes. The Vaccine Manager in this module is an immunization management tool that augments medical surveillance programs. This tool allows for use of employee badges and scanning devices collect and validate immunization data. It also sends confirmation emails, provides a secure patient portal to retrieve copies of formal, signed immunization documentation, and enables the recipient to fill out an electronic survey to provide near-real-time feedback.

The Workplace Incidents Management module, also named as Accidental & Injury, implemented in 2017, captures, records, and tracks incidents that are violations of

FDA-RFQ-18-1196672 Page 8 of 67 laboratory and safety protocols. This module provides linkages to the eComp program for reporting workplace injury and illness for investigation by the FDA Safety Staff. The Workplace Incidents Management module provides custom reporting and analytical features for OSHA and Department of Labor forms and reporting.

The Institutional Review Board (IRB) module, PI Dashboard, implemented in 2015, provides tracking of the status of the research protocols using human subjects. The IRB module is used by Research Involving Human Subject Committee (RIHSC) for the creation, submission, review, and approval of all research packages for RIHSC. This module provides electronic record keeping in which FDA sponsors maintain accurate and complete study records to include the current and archived versions of the protocol, consent form, and study amendments; establishes the location where original source materials and records or data are generated over the course of study, and assure the confidentiality of all records.

6 GENERAL REQUIREMENTS

The contractor shall provide IT Lifecycle support activities for HealthRx’s Nexus COTS 4.x or equivalent modules that provide the framework for FDA’s SIPS.

7 SPECIFIC REQUIREMENTS

7.1 PROJECT MANAGEMENT SUPPORT (Firm Fixed Price)

7.1.1 Project Management

The Contractor shall provide project management oversight to ensure that the scope, schedule, quality, and cost are monitored and controlled throughout the duration of this contract. The Contractor Project Manager (PM) shall provide overall support including resource and risk management. To ensure technical compatibility with FDA's technical environment, 508 compliance, and reduction of IT security risks, the Contractor PM shall assist in the following IT related management activities as they pertain to this contract release, change control, configuration, and IT investment management.

Specifically, the Contractor PM shall perform the activities described in the following sections.

7.1.2 Kick-Off Meeting

The Contractor Project Manager shall host a "kick-off meeting" within seven working days of award. The meeting may be held remotely or onsite. The purpose of the kick-off meeting is to introduce the Contractor staff including the key personnel to the COR and the SIPS stakeholders and discuss the Contractor's approach to meeting the requirements of this SOW.

7.1.3 Project Management Plan

The Contractor shall provide a Project Management Plan (PMP) to the COR describing the technical approach, organizational resources and specific roles, communication approach, quality control, risk management, change management, configuration management, FDA-RFQ-18-1196672 Page 9 of 67 h release management, integration management, deliverable management, work breakdown structure (WBS), and project schedule, to be employed to meet the cost, performance, quality, schedule and deliverable requirements throughout the execution of this contract.

The PMP shall be delivered within 30 days of award. The Contractor shall provide a three-level WBS which shall be finalized within 30 days of award. The Contractor shall develop a Project Schedule which shall be completed in accordance with Project Management Institute (PMI) standard practices, and incorporate all deliverables, EPLC milestones and stage gates as drafted in the Project Process Agreement (PPA). The PMP shall include a communication plan that identify roles and responsibilities of FDA personnel, contractors, and subcontractors and submit to the COR for approval within 30 days of award.

7.1.3.1 Monthly Progress Reports

The Contractor Project Manager shall provide monthly status reports to the FDA COR or Project Manager. Formal monthly status reports shall be delivered to the COR in accordance with the delivery table at the time on or before the 10th of the calendar month following the reporting month. Status reports shall include:

• The overall progress of all systems and applications covered under this contract

• Progress on deliverables against the project plan

• Level of effort per application and labor categories

• Identified risks and mitigation strategy

• Accounting for deliverables

• Action items for the following period

• Any current or anticipated problems with scheduled activities

• The status of the previous month’s invoice

7.1.3.2 Final Report

The final report shall include a summation of the work performed and shall be in sufficient detail to describe comprehensively the results achieved for the entire contract period of performance. The final report shall include all deliverables that will fully document the outcomes of the tasks outlined in the scope of work. The final report shall be submitted on or before the last day of the contract performance period. The report and model must comply with OMB and HHS guidelines related to Information Quality (available at http://aspe.hhs.gov/infoquality) and Information Technology and Section 508 Compliance requirements.

7.1.3.3 EPLC Support and Documentation

The Contractor shall support the FDA EPLC process. Within one month after the Contract award, the Contractor Project Manager shall provide a signed FDA EPLC Project Process http://aspe.hhs.gov/infoquality http://aspe.hhs.gov/infoquality

FDA-RFQ-18-1196672 Page 10 of 67

Agreement (PPA) to the COR for each release.

The PPA shall outline in detail the list of EPLC artifacts/deliverables, per FDA EPLC framework, to be delivered with each phase on the lifecycle process. At a minimum, the release artifacts shall include either new or updated versions of the following:

• Project Schedule

• Project Management Plan

• System Requirements Specifications

• System Design Document

• Data Model

• Release Test Plan

• Test Cases

• Requirements Traceability Matrix

• Test Report

• Version Description Document

• User Manual

• Operations and Maintenance Manual

The Contractor shall provide technical coordination (initiating updates to EPLC documentation, facilitating release schedules, and discussions on Change Requests / minor enhancements) among stakeholders and documentation management. The Contractor shall develop and provide EPLC and other documents (as appropriate) to demonstrate compliance with data quality, EPLC, IT security and other standards and constraints per IDIQ

SOW.

The Contractor shall ensure all EPLC documentation is free from typographical errors, grammatical errors and navigational problems. The Contractor shall create new document in accordance with EPLC if there is no older version available or the older version is obsolete.

7.1.3.4 Configuration Management

The contractor shall conduct configuration management in accordance with FDA change management and testing policy. The contractor shall practice version control of all SIPS project documents, applications and database components using FDA approved tools such as SharePoint for documents. The contractor shall document all changes in code, test scripts and test results.

The contractor shall perform the following representative activities for Configuration Management:

• Follow OTD / DAS Change Review Board (CRB) process

FDA-RFQ-18-1196672 Page 11 of 67

• Provide technical information for proposed change requests (e.g., technical feasibility, technical alternatives and estimated level of effort (LOE) required to complete the change

• Participate in OTD / DAS CRB and OIMT Change Control Board (CCB) meetings

• For agile development, the contractor may be required to support configuration management techniques such as continuous integration.

• Log and track all system changes FDA approved version control system such as

Subversion (SVN)

• Support configuration management activities aligned with the designated Order’s software development methodologies, which may include waterfall, agile or iterative approaches.

7.1.3.5 Change Management

The contractor shall adhere to FDA’s Change Management process to ensure an orderly and effective procedure for tracking the submission, coordination, review, evaluation, categorization, and approval of all changes to the project’s baselines.

Types of Changes There are four forms of changes that may be applicable to SIPS during performance of the contract: PCRs, CRs, Defects, and ICRs. These changes will be tracked and managed using the FDA’s standard JIRA CM tool.

• Change Request (CR) – These change requests outline changes to the original baseline of the approved scope, requirements, technical changes, etc. Change Requests are tracked and maintained in the JIRA application. The formal change request process for CRs is outlined in this document.

• Defect – A defect is a condition in a software product which does not meet a software requirement or end-user expectations. Defects are tracked and maintained in the JIRA or HP ALM application and the formal process for defects is outlined in this document.

• Investigational Change Request (ICR) – Investigational Change Requests are CR’s that needed more than six hours of analysis in order to determine a technical approach and level of effort. Investigational Change Requests are tracked and maintained in JIRA.

• Process Change Request (PCR) – Process change requests propose changes to approved EPLC documentation. Changes to approved EPLC documentation must be approved by all signatories of the original document. All EPLC documentation will be managed, reviewed, and updated thru Version Manager (VM) or SharePoint and/or Enterprise Content Management System (ECMS).

The contractor shall:

• Review SIPS Change Requests

• Submit Changes Requests for management approval

• Log Change requests

• Collaborate with SIPS stakeholders to prioritize Change Requests.

FDA-RFQ-18-1196672 Page 12 of 67

7.1.3.6 Release Management

The Contractor shall provide release management activities and work with IT support, Data Center Stakeholders, and business stakeholders to support the development and deployment of system releases to the appropriate Data Center environments. Initial, Major, Minor, or Emergency/Patch release types are defined as:

• Major Release: A major release is a planned release that provides major functional changes to or extensions of the product. Major releases are usually not backward compatible with previous releases.

• Minor Release: Scheduled release to include defect corrections and/or minor enhancements system components already in production, including software changes necessary to support system or Commercial-Off-the Shelf (COTS) patches. Minor releases are backward compatible with all releases up to the last prior major release.

• Emergency Release: Release to correct one or more problems with a system that is negatively impacting functionality and requires prompt resolution.

Emergency Releases are added to the project schedule as needed upon approval by COR and/or Project Manager.

Representative activities for Release Management are:

• Conduct quality assurance of release documentation

• Collaborate with business stakeholders to create release schedules and deployment into production is completed in accordance with agreed upon schedule.

• Ensure deliverables are delivered in the appropriate format to the COR.

• Request CHDC Resources for Pre-Production and Production, Request ICCB

(Infrastructure Change Control Board) approval for deployments.

• Represent RFC(s) (Request For Change) at ICCB meeting.

• Deliver final “Release Package" to FDA OIM Configuration Management

Team,

• Validate successful deployment to target environment.

• Evaluate all Change Request and Defect candidates for each release to ensure quality and performance standards.

7.2 Renewal of HealthRx Nexus COTs v4.x and associated Software Maintenance or Equivalent (Firm Fixed Price)

7.2.1 Annual Renewal of HeatlhRx Nexus COTs v4.x or Equivalent The contractor shall renew FDA’s annual subscription to Nexus COT v4.x Enterprise-wide License suite or Equivalent. The renewal of the Nexus COTs v4.x enterprise license suite shall include the following HealthRx Product Numbers, Product Descriptions, and Quantities or equivalent that are currently implemented at the FDA and apart of the SIPS system:

NAIC-001-A – Nexus Application Container – Qty 1 PID-001-A: PI Dashboard - Qty - 1 PID-001-8: PI-Dashboard Add-on Domain (IRB, Biology, Chemical, Radiation) - Qty 2 LSM-001-A Laboratory Safety Mangaer – Qty1 INV-001-A Inventory Manager – Qty 1

FDA-RFQ-18-1196672 Page 13 of 67

DAR-001-A: Data Analytics and Reporting – Qty 1 ESM-001-A: Electronic Surveillance Manager PID Connector – Qty 1 EMR-001-A: Electronic Medical Record – Qty 1 CAM-0001-A: Clinical Access Manager – Qty 1 VIM-001-A: Vaccine Manager – Qty 1

The contractor shall ensure the Enterprise License supports up to 16,000 end users.

Note: The owner of the Nexus licenses or equivalent shall be listed as the FDA, and not the reseller. The renewal of the FDA SIPS –Nexus Software licenses or equivalent shall also include software upgrades and technical support throughout the Period of Performance (PoP).

7.2.2 Nexus COTs v4.x Software Maintenance and Support or Equivalent HealthRx Nexus COTs v.4.x Enterprise Licenses or equivalent software maintenance shall include access to the latest version of all software products covered under the subscription and provide the following:

• Software Upgrades – New versions of the software

• Software Updates – Service packs to fix specific issues

• Hot Fixes – Temporary, urgent fixes when a workaround cannot be found

• Back Porting – Fixes in older versions in case it is not possible to upgrade to the latest version quickly

7.2.3 TECHNICAL SUPPORT

As part of the Nexus COTs v4x Enterprise License renewal or Equivalent the contractor shall provide a technical support to meet following requirements:

• Monday-Friday, 8AM to 8PM Phone Support, Eastern Standard Time (EST) for other than Severity 1 issues or provide standard company hours.

• 24 x 7/365 support with two-hour response time for Severity 1 (production system down or otherwise severely impacted or where core business functions are blocked) issues

• 24 x 7/365 via SIPS application to submit technical support requests via email.

7.3 OPERATIONS AND MAINTENANCE (O&M) SUPPORT (Firm Fixed Price)

The Contractor shall provide system sustainment and maintenance support of SIPS, as described in the following subsection. The Contractor shall ensure all O&M activities follow the FDA EPLC processes for system development lifecycle activities and the Contractor shall use the tools and software as provided by the COR at contract award and approved by FDA. The Contractor shall provide the full range of O&M support services including as identified below:

7.3.1 IT LIFECYCLE SUPPORT

The Contractor shall ensure that the SIPS system uptime is during normal business hours, 8am – 8pm, Monday-Friday. SIPS system has a 12 hours per day, 5 days per week operational requirement. The contractor shall ensure staff and resources provide support for SIPS Systems during the normal business hours (8:00 am to 8:00 pm Eastern Time, Monday-Friday). The

FDA-RFQ-18-1196672 Page 14 of 67 contractor shall perform technical upgrades and refreshes as directed, required and/or mandated by the FDA for maintenance and support activities (normally scheduled after hours or weekends).

The contractor shall be responsible for maintaining the deployed system to keep it operational and in compliance with FDA EPLC and other policies by:

• Maintaining code, scripts, designs, documentation, reports, and templates;

• Analyzing and reporting the impact of infrastructure, software upgrades, capacity, and other changes to the OTD / DAS SIPS environments;

• Participating in the Change Management process and responding to Change Request

(CR) tickets

• Conducting System Administration activities, Coordinating back-up and recovery support;

• Conducting issue identification and management;

• Collaborating with database administrative staff to ensure availability of technical environments;

• Conducting performance monitoring and tuning;

• Monitoring data quality and conducting quality assurance;

• Providing integration and interface support;

• Provide emergency patching and troubleshooting support to maintain or restore system availability

• Deploying regular patches and updates as they become necessary or available

• Performing database refreshes in the Development, and Test environments, as needed.

For any future refreshes in DEV and TEST environment, FDA requires masking production data. The contractor shall gather information and steps for data masking for SIPS and provide the approach and steps to conduct and verify the masked data.

• Responding to Data Calls. Data calls often involve financial status, computer or hardware details, technical attributes of the SIPS Systems, or security audits. Prompt turn-around time is often required for data calls; this will be identified by COR at the time the data call is issued. On Average, the volume of data calls is approximately 54 per year. Historically the LOE for data calls is between 1-3 hours.

• Collaborating with data center teams for any FDA-wide infrastructure or technology upgrades (such as Oracle or SQL database, , Java and any Operating system upgrade) related to SIPS system. The contractor shall collaborate with data center teams to provide support for SIPS verification and troubleshooting, as needed.

• Providing responsive and proactive operations support to include working with FDA Data Center contractors to identify and resolve SIPS system outages and any performance issues. During normal business hours, the contractor shall engage and begin troubleshooting within 30 minutes of being notified of any SIPS system outage or performance issues.

• Ensuring all processes are documented properly in an operations manual. Updates to the manuals will be expected with each maintenance release.

• Notifying the FDA Project Manager/COR and business owners of application and/or database problems within 30 minutes during normal business hours.

• Utilizing FDA IT automation tools to deploy the application, manage configurations, and install server software if applicable

FDA-RFQ-18-1196672 Page 15 of 67

• Collaborating with the data centers and developers of other interfacing applications to troubleshoot and resolve the issue. Types of collaboration required are communicating issues, sharing EPLC documents and workflows, scheduling access to environments, communicating anticipated release dates.

• Ensuring all processes are documented properly in an operations manual. Updates to the manuals will be expected with each maintenance release.

• Updating Test contingency and disaster recovery plans on an annual basis.

7.3.2 Emergency Maintenance Support

The Contractor shall support emergency requests for maintaining SIPS in CHDC and WODC environments during weekend and off- office hours. The emergency support could be required for tasks such as patching support in the event the CHDC contractor request support;

validation of applications after patching; troubleshooting in case of maintenance;

performance, or outage of an application/module/database; providing status updates to stakeholders; and emergency release, if needed.

7.3.3 Security Related Support

The Contractor shall support Authority-To-Operate (ATO) efforts including performing required security-related modifications as a result of ATO efforts. The Contractor shall investigate and report security incidents and events. The Contractor shall support system’s Certification and Accreditation (C&A) and Annual Information Security Risk Assessment.

7.3.4 Database Administration Support

The Contractor shall provide database administration support for SIPS in support of releases, resolution of related issues attributed to the database and any database upgrades. The Contractor shall assist the data center personnel with database administration for SIPS databases. The Contractor shall:

• Perform database refreshes in the Development, Test, and Pre-Prod environments. It is anticipated that between 3-4 refreshes will be conducted annually to include all environments.

• The Contractor shall develop and execute database cleanup scripts and document the results and/or any discrepancies.

• Provide recommendations for database performance improvements and O&M responsibilities and procedures.

• Perform logical and physical data modeling with each release. The updated data models shall be provided using the Erwin tool, along with an updated data dictionary.

• Create, execute, and maintain scripts, jobs and procedures.

• Support maintenance of databases and release requests in development, test, pre-production, and production environments.

• Support audit trails in accordance with the System Security Plans. Provide and maintain database documentation.

7.3.5 User Support

The Contractor shall provide support to SIPS users by performing the following activities:

FDA-RFQ-18-1196672 Page 16 of 67

• Creating, maintaining and fixing database user accounts, fixing system user accounts roles and permissions, and providing administrative support.

• Maintain the administration of system users and their roles.

• Performing data corrections required in the database to address inadvertent user actions.

• The contractor shall assist users with uploading and storing documents in Sharepoint.

• Providing regular status updates and communications regarding all open tickets to the users and, for high and urgent priority tickets, to the COR and IT PM.

7.3.6 TRAINING SUPPORT

The Contractor shall:

• Provide updated training materials and user manual for each release of the system.

• Provide computer based end user training, user guides, sample reports and views to improve user understanding of SIPS features and functionalities.

• Provide user training for DME enhancements listed in SOW section 7.6.

7.4 HELP DESK SUPPORT (Firm Fixed Price)

The Contractor shall provide help desk support to SIPS Program Team and SIPS users.

Specifically, the contractor shall:

• The Contractor shall operate the Help Desk by performing such technical and administrative services as taking phone inquiries and responding to email or other inquiries, documenting and triaging problems, troubleshooting the issues, coordinating with data centers and FDA Subject Matter Experts (SMEs) and escalating issues to the appropriate FDA business units when necessary.

• The contractor shall set up a helpdesk integrated with ERIC and ServiceNow to have support tickets generated automatically. The contractor shall also produce reports explaining problem resolution, metrics, and an inventory of inquiries. Maintain issue tracking in JIRA to record all technical support interactions.

• Maintain Tier 1 and Tier 2 support for all inquiries.

o Tier 1 – Any issue can be answered from knowledge base or FAQs by the contractor. Should be passed up to Tier 2 if SMEs or COTS vendor are required for evaluation.

o Tier 2 – Any request that cannot be resolved using FAQ or knowledge base will be escalated to Tier 2 requiring Subject Matter Experts (SMEs) or COTS vendor resources to analyze and resolve the issue. All the tickets requiring administrative privileges and account management shall be directly escalated to Level 2. The issue may require escalation through ERIC or ServiceNow system for FDA data centers for database, application server and network support.

o Tier 3 – If a ticket requires application changes, it will be escalated to Tier 3. The contractor shall work with the Nexus COTs or equivalent vendor to develop, test and apply emergency patches or service packs.

FDA-RFQ-18-1196672 Page 17 of 67 o Additionally, users may report their issues to FDA ERIC help desk staff. These will be redirected to SIPS help desk for further support. The contractor shall coordinate with ERIC help desk to collect any additional information for troubleshooting and work with data centers, users, and SMEs for timely resolutions of submission issues.

o The contractor shall use the FDA-provided current ticketing system (ServiceNow) to track, prioritize, and assign service tickets and report on help desk metrics. The help desk shall prioritize tickets based on FDA’s priority levels shown in the table below.

Severity Help Desk Severity Description Response

• System wide outage or system functionality is not working or,

• 25% or more of customer base is impacted or,

• No work around available

• 15-minute initial response time to project leadership once the Severity 1 ticket is created either internal or external

• Update to project leadership must be provided every two hours.

• Updates to the user community as necessary and determined by the

COR/PO

• Critical impact to users or,

• Subset of users is impacted (< 25%) or,

• Work around is available

• 30-minute initial response time

• Updates to the user community as necessary and determined by the COR/PO

• Not a critical impact to users

• Work around is available

• Urgent management data requests

• High-priority system/application change requests

• Update from Operations Manual/Status Report

• The contractor shall periodically update Standard Operation Procedures (SOPs), Frequently Asked Questions (FAQs) and how-to guides based on experience and issues identified during prior interactions with users during Help Desk support so that users can help themselves when possible.

7.5 Data Reporting and Analytics

The contractor shall ensure the proposed COTS solution has Data reporting and analytics capabilities. Specifically, the COTs solution shall be able to perform data mining, data discovery, signal management (identify, analyze and document signals). The solution shall utilize SIPS data and any other external data sources applicable to SIPS.

Services related to Data Reporting and Analytics include:

1) Collect data requirements from end users

2) Configure solution to add data reporting elements

3) Develop canned reports

FDA-RFQ-18-1196672 Page 18 of 67

4) Create user roles and role based dashboards

5) Design, develop, test and implement reports

6) Ensure report integrity, quality, and accuracy during system releases and hardware upgrades.

7) Assist stakeholders develop ad-hoc reports

8) Provide support to end users on existing reporting capabilities

7.6 SIPS DEVELOPMENT, MODERNIZATION, AND ENHANCEMENTS (DME) (Labor Hour)

The contractor shall provide DME of SIPS to improve system usability and functionality. The following DME activities shall be conducted:

7.6.1 Electronic Medical Records DME

The contractor shall enhance the Electronic Medical Records module in SIPS to provide the FDA Occupational Health Service with the following added functionality:

• FDA-specific visit process workflow management

• FDA-specific form generation

• FDA-specific data capture

• FDA-specific patient access requirements

• Medical Doctor review and approval

• Platform to accommodate Future FDA form /workflow requirements The details on the functionality that is to be developed in order to provide these benefits are outlined below.

Functional Details of EMR DME

1. Workflow Management – Support FDA specific visit flows based on visit type

a. Logic to present forms specific to the visit type

i. Workflow will be managed and updated consistently

ii. Medical Doctor review and approval (visit-type dependent)

2. Forms Management- FDA specific forms development and management

a. Logic to capture the data relevant to the visit based on provider input

i. Forms to be provided

ii. Forms will continue to be created and updated consistently

b. Current forms requiring development with FDA stakeholders

i. Pre-placement

ii. Encounter Notes

iii. Visit Type Forms

iv. Nurse Protocol

v. Immunization Forms

vi. Surveillance Forms

3. Employee Demographics – FDA-specific patient demographic details

FDA-RFQ-18-1196672 Page 19 of 67

a. Construct updated database schema to support FDA employee information

i. Received from interface to FDA employee directory (periodically updated)

7.6.2 Inventory Manager DME

The contract shall configure the Inventory Manager module of the Nexus COTs v.4x or equivalent product. The Inventory Manager module shall provide regulatory inventory compliance using a single management interface that allows the FDA to manage multiple inventory types. The contractor shall ensure the Inventory Manager supports catalog information, stock information, and cradle to grave inventory workflow management for radiation, chemical, biological inventory types, as well as equipment. The contractor shall configure inventory management forms to meet specific needs of the FDA and customize forms per the domain (Radiation, Chemical, Biological, , and Equipment) to accommodate the disparate requirements of each module in SIPS. The contractor shall ensure the Inventory Management enhancements provides the FDA with streamlined inventory management in a secure environment ensuring adherence to all regulatory compliance.

The contractor shall configure the Nexus COTs v4.x or equivalent Inventory Management module to include the following salient characteristics and functionalities:

Salient Characteristics:

• Inventory support for each of the following domains

a. Radiation Inventory

b. Chemical Inventory

c. Biological Inventory

d. Equipment Inventory

• FDA-specific inventory workflow management process support for each domain

• FDA-specific form configuration to accommodate agency and domain requirements

• Configurable to accommodate any future FDA-specific business requirements requiring workflow or form updates

Functional Details

1. Workflow Management – Inventory management from cradle to grave

a. Logic to support business process needs

i. Support individual needs of each domain

ii. Configurable to support future updates or changes in workflow

2. Forms Management- FDA specific forms development and management

a. Support individual needs of each domain

b. Forms will continue to be created and updated consistently

c. Configurable to support future updates or changes in content/sections

3. User Experience / Interface Enhancements

a. User roles / views to support business process needs of FDA roles

FDA-RFQ-18-1196672 Page 20 of 67

b. Roles / views separated by domain

i. Build upon each other to allow access across domains

7.6.3 Workplace Incident Manager (Accidental & Injury/Workplace Injury and Illness Manager) The contractor shall configure the Workplace Manager module to improve the workflow management tool to be more robust and support the investigation process conducted by FDA safety. The updates to the system shall provide the following added features:

• Updates to forms, investigation workflow changes, and start page options that will allow to easily accommodate different incidents types and reflect changes in process quickly.

• Structured process with transaction history to allow for cross communications while protecting the data collected as part of the investigation.

• OSHA questions to meet the data requirements for OSHA forms 300, 300A and 301 that, with the completion of these enhancements, will be included along with reports out of the box to meet the formatting requirements of DOL for yearly reporting.

Functional Details

1. Start Page Functionality

a. Select details specific to incidents in order to show only relevant sections

i. Streamline paper work required for incident investigation

2. Workflow Management

a. Develop and support FDA specific business processes for incident investigations

i. Support future updates and changes to that process

b. Manages flows and privileges at each step in the process

i. Ensure data authenticity and integrity

ii. Functionality to support returns (pushing back in the workflow)

iii. Functionality to support amendments (changes in the original content)

1.…