Attachment_2_-_Task_Order_1_SOW_for_SRP_OM_and_DME_Support_A1.pdf

Attachment 2 - Task Order 1 SOW for SRP Operations & Maintenance and Development Modernization and Enhancement (DME) Support

Contents

1.0BACKGROUND

2.0SRP SYSTEM OVERVIEW

3.0PURPOSE

4.0SCOPE/OBJECTIVES

5.0TASK AREAS

5.1 Transition in (Optional)

5.1.1 Transition In Tasks

5.1.2 Transition-In Plan

5.1.3 Transition-In Meetings

5.1.4 Transition-In Deliverables

5.2 Operations & Maintenance Support Tasks

5.2.1 Infrastructure O&M Tasks

5.2.2 Operational O&M Tasks

5.2.3 Operations and Maintenance Related to Documentation

5.2.4 Operations and Maintenance Related to Security

5.2.5 Operations and Maintenance Related to Assessments and Reviews

5.2.6 Service Level Agreements

5.2.6.1 Communications

5.2.6.2 Support

5.2.6.3 Level 1 Help Desk

5.2.6.4 Level 2 Technical Support

5.2.6.5 Level 3 Application Maintenance

5.2.6.6 Performance Improvement

5.2.6.7 Expected Hours of Application Availability

5.2.6.8 Maintenance Windows

5.2.6.9 Escalation Procedures

5.2.6.10 Deliverables

5.3 DME 19

5.3.1 Introduction

5.3.2 Spanish Language Translation Task

5.3.3 Requirements and Design Phase Task

5.3.4 Product Development and Testing Phase Task

5.3.5 Implementation and Deployment Phase Task

5.3.6 Technical Project Management Task

5.3.7 Deliverables

6 KEY PERSONNEL

7 IT SECURITY

8 PERIOD OF PERFORMANCE AND TYPE OF TASK ORDER

9 PLACE OF PERFORMANCE

10 GOVERNMENT FURNISHED PROPERTY

11 SECURITY AND PRIVACY

12 CONTRACTOR COMPLIANCE

13 508 STANDARD REQUIREMENTS

1.0 Background

The Office of Biotechnology Activities (OBA) of the National Institutes of Health (NIH) has partnered with the Food and Drug Administration (FDA) to develop an adverse event and product problem reporting system, called the Safety Reporting Portal (SRP).

The FDA Safety Reporting Portal (SRP) is an adverse event and product problem reporting system that supports federal-wide submissions of mandatory and voluntary safety reports from manufacturers, distributors, and users of products that may result in adverse events in humans or animals. Recent legislation such as the Food and Drug Administration Amendments Act (FDAAA) of 2007 and Food Safety and Modernization Act (FSMA) mandate requirements that have guided and continue to guide the mission and development of SRP. SRP currently supports multiple Centers within the FDA including: Office of Foods (OF), Center for Food Safety and Applied Nutrition (CFSAN), Center for Tobacco Products (CTP), Center for Veterinary Medicine (CVM) and Center for Drug Evaluation and Research (CDER).

The SRP uses a harmonized set of data elements and associated attributes contained in the Basal Adverse Event Report (BAER), which are based on the recommendations of the Federal Adverse Event Taskforce (FAET). All submitted reports are transformed into a standardized structured data format and must then pass through the FDA Electronic Submission Gateway (ESG). Reports are then validated, processed, and stored on FDA back-end databases, which are hosted at the FDA’s Contractor Hosted Data Center (CHDC), for review and analysis. The FDA adverse event reports analysis and management servers are developed and maintained independently by each FDA Center responsible for the regulatory data.

Development of the SRP was initiated in 2008 and in May 2010, Release 1.0 of the Safety Reporting Portal was deployed on the SRP production environment hosted at the NIH/ Computer Information Technology (CIT) data center. Since then, updates, additional functionality, and new and revised reports have been added incrementally in a series of patches and Service Packs. The SRP system complies with the Computer Security Act and OMB Circular A-130 and is consistent with the NIH Master Enterprise Security Plan as well as the companion NIH IT Security Requirements document.

In collaboration with FDA, NIH supports the continuing development and Operations & Maintenance (O&M) support of the SRP. The government project manager is supplied by the FDA Office of Information Management & Technology (OIMT). Under this management structure, centers and agencies may initiate tasks to develop new reports, modify reports that they have previously developed, enhance the core functionality of the SRP system itself, or develop or modify closely related systems or services.

2.0 SRP System Overview

The Safety Reporting Portal (SRP) is a public-facing web application that enables the Food and Drug Administration (FDA) to collect data related to adverse health events and problems associated with specific FDA-regulated products in support of the agencies Adverse Events program. SRP enables industry, health professionals, consumers, and others to report adverse events or problems associated with these products by providing access to web-based rational questionnaires (RQ) tailored to those product categories and specific to each FDA Center. The information collected via the RQs is then routed to the appropriate backend databases allowing the FDA to have real time access to reports for more rapid analysis of safety problems and threats to public health.

The SRP System, located in the NIH Center for Information Technology (CIT) environment, is comprised of several different, discreet, interoperable systems including the portal itself, multiple Rational Questionnaires (RQs), supporting systems and services. The Electronic Submissions Gateway (ESG) is located in FDA and is used by many external systems and users to submit reportable data to FDA. The SRP also uses the ESG to deliver the collected adverse event reports to the FDA internal servers. The FDA adverse event reports analysis and management servers are developed and maintained independently by each FDA Center responsible for the regulatory data.

These are the downstream systems within FDA receiving data from the SRP System.

The SRP System is a high availability/high reliability system where downtime is only permitted in the production environment during scheduled maintenances and/or release windows. In the rare event of an unscheduled outage, work to resolve the outage is required on a 365/24/7 basis.

3.0 Purpose

The overall purpose of this contract is to manage and provide comprehensive technical support services for the Safety Reporting Portal (SRP) system, primary stakeholders of the SRP (various FDA Centers and NIH Offices and Institutes), and the users of the SRP. The contractor will also provide the necessary proactive and responsive user support services while assisting the NIH and FDA in enhancing the Safety Reporting Portal (SRP) in the areas such as:

1. Develop new Rational Questionnaires

2. Develop new features of the SRP as directed by the SRP stakeholders

3. Translate the application into different languages

4. Manage and maintain multiple integration points with downstream systems

It is important to note that the Safety Reporting Portal is designed to support multiple agencies and during its Operations and Maintenance (O&M), the contractor is expected to ensure that the requests for changes or new requirements from one stakeholder must not adversely impact other stakeholders. This would require change control management and design coordination with the stakeholders to ensure that the changes are acceptbale to all stakeholders.

4.0 Scope/Objectives

The scope of this effort is to obtain all support services necessary to provide full range of application software maintenance, enhancement, development, and management support. In order to accomplish the above stated objectives, the contractor shall specifically provide complete O&M and DME support for the Safety Reporting Portal including:

• Maintain and support the SRP production system running at NIH CIT

• Maintain and support the SRP staging environment running at NIH CIT. The staging environment is a replica of the production environment and is primarily used to validate a build for production.

• Maintain and support (contractor provided) development and testing environment for the SRP to develop, debug, and fix issues raised in the production system. The development environment must support source code control management and be able to support HHS EPLC development methodology.

• Conduct feasibility and requirement analysis for enhancements to the existing SRP system, infrastructure and its production environment.

5.0 Task Areas

5.1 Transition in (Optional)

The purpose of the Transition-In task is to provide an orderly transition from the incumbent Contractor to the successor Contractor. It is the responsibility of both the incumbent and the successor Contractor to ensure a smooth transition from the incumbent Contractor to the successor Contractor. The successor Contractor shall work toward the Government’s goal of ensuring minimal disruption to services and support for users.

The successor Contractor shall work with the incumbent Contractor during the 6-week Transition- In timeframe. At the end of the 6 weeks, the successor Contractor shall be responsible for fully supporting the Task Order. The incumbent Contractor will provide limited SME support to the successor Contractorfor 6 more weeks, this is the incumbent’s Transition Out timeframe. See Table 1 below.

Table 1: Transition Timeline

Day 1 – Day 42 (Start of Transition In)

Day 43 – Day 84 Day 85+

OM Incumbent Successor Successor

Transition Out Incumbent

Transition In Successor

Working with the incumbent Contractor and the COR, the successor Contractor shall develop a plan to take over on-going work from the incumbent Contractor as soon as possible after the Task Order begins.

The incumbent Contractor will be performing Transition-Out activities for an estimated three month timeframe starting at the Task Order award. During this time the incumbent Contractor is responsible for ensuring the following incumbent Transition-Out activities are completed:

1. System documentation updated as of the most recent release (e.g., system architecture, user guides, release documentation, design documentation, run books).

2. Outstanding Change Requests (defects and enhancements) captured in the appropriate configuration management tool.

3. Source code updated in the appropriate configuration management tool including source code in test and development (e.g., database, application, services, web pages, and websites).

4. Regular maintenance activities documented for all systems.

5. Current life cycle process documentation related to the SRP systems updated.

6. Completed responses to data calls.

The FDA will provide the successor Contractor with all the necessary documentation in support of these tasks.

5.1.1 Transition In Tasks

The successor Contractor shall perform the following tasks:

• Conduct and coordinate all on-boarding activities with the Government and obtain secure badging for team personnel. This activity shall start immediately after the Task Order award to ensure personnel are productive as soon as possible.

• Ensure that the appropriate staff are available to work with Subject Matter Experts (SMEs) from the Government and the incumbent Contractor immediately after the Task Order award.

• Familiarize themselves with the SRP Systems, system documentation, release documents, source code, project documentation, and EPLC methodology.

• Engage in regularly scheduled meetings including, but not limited to those defined in the (Transition-In Meetings) section below.

• Familiarize themselves with the current documented enhancements for the SRP system.

• Develop a Baseline of existing defects (Legacy Defects) by the end of the Transition-In period. As part of the Baseline and working with the Government, the Contractor shall identify a plan for resolving the Legacy Defects (i.e., defects to be resolved during the Base Period, defects to be resolved beyond the Base Period, or defects that will be closed without resolving).

• Familiarize themselves with any current regular maintenance activities.

5.1.2 Transition-In Plan

The Transition-In Plan is initially submitted with the technical proposal and it describes how the successor Contractor will provide continuous high-quality service to the SRP as the incumbent Contractor prepares to Transition-Out. The successor Contractor shall update this plan as needed throughout the Transition-In period to ensure alignment with current activities. Changes to the Transition-In Plan shall be reviewed during the Transition Plan Briefings (see Table “Transition Meetings”) for Government staff. The first Transition Plan Briefing shall occur within 1 week of award. During the first Transition Plan Briefing, the second Transition Plan Briefing will be scheduled to occur within the Transition-In period. The Contractor shall implement the updated Transition-In Plan only upon approval by the COR.

The Transition-In Plan shall identify tasks, deliverables, and milestones to ensure an orderly and complete transition. At a minimum, the plan shall include:

o Roles and responsibilities for Contractor staff o Schedule and milestones for completing the transition o Process for progress reviews, identifying problems, and ensuring prompt problem resolution o Methodologies for conducting and ensuring a seamless transition o Orientation phase to introduce Government personnel, programs, and users to the

Contractor team, tools, methodologies and business processes o Requested equipment and the personnel to whom it will be assigned o Technical and management concerns o Identified risks and mitigation strategies to ensure minimal disruption to system and system users

5.1.3 Transition-In Meetings

The Contractor shall attend transitional meetings as outlined in Table “Transition-In Meetings”.

In order to ensure productive meetings, it is strongly recommended that key participants attend the Transition-In meetings in person.

Meeting/Activity Description Typical Location(s)

Estimated Occurrences

Project Kick-off All Hands meeting for staff introductions during the first week of period of performance

WFN, WO 1

Transition-In Plan Briefings

Project Leadership meetings to refine the original Transition-In Plan

WFN, WO 2

Transition-In Meetings

Detailed discussion of transition related topics during the Transition-In timeframe

WFN, WO 30

Code Review Meetings

Meetings to review software code

WFN, WO 30

Priority Tasks and Issues Meeting

Weekly status meeting with key team members to review status of all SRP projects, discuss action items, and dependencies.

For these meetings, the Contractor shall ensure that the following agenda items are addressed:

• Status of Task Order priority activities

• Schedule status

• Identification of risks/issues

• Status of defects

• Production backlog

WFN, WO 6

Future Priority Planning Meeting

Weekly status meeting with OIM and to discuss and agree upon the prioritization of projects and tasks, manage risks and issues, and discuss future planning activities. For these meetings, the Contractor shall ensure that the following agenda items are addressed:

WFN, WO 6

• Overall status of project activities and goals to help determine priorities of new SRP projects/tasks

• Assumptions, risks, and other issues that could impact the project tasks, systems or projects

• Staffing changes

5.1.4 Transition-In Deliverables

The Contractor shall create the following Transition-In deliverables as outlined in Table “Transition-In Deliverables”:

Deliverables Reference Frequency Deliver To

Legacy Defect Baseline Report

Transition- In Tasks

At the end of the Transition-In Period COR or their designee

Transition- In Plan

Transition- In Plan

First Update is required 1 week after award. Review and update as indicated by the COR. Final Transition-In Plan is required at the end of the Transition-In period of performance. The final Transition-In plan should reflect the status of all Transition-In activities and serve as close out documentation of this effort.

COR or their designee

5.2 Operations & Maintenance Support Tasks

The scope of the O&M support is to obtain all services necessary to provide full range of application software operations, maintenance, and management support. The SRP is designed to support multiple agencies and during its O&M, the team is expected to ensure that the request for changes or new requirement from one stakeholder must not adversely impact other stakeholders. This requires change control management and design coordination with the stakeholders to ensure that the changes are acceptable to all stakeholders. Operations &

Maintenance support tasks focuses on technical environment compatibility, upgrades, operational support, security adherence, issue identification, defect resolution, administration support, performance tuning, and help desk support necessary to maintain the availability, reliability and security of the SRP system. Maintenance releases typically occur once or twice per year unless an emergency arises. There are a maximum of 2 major scheduled SRP releases per year.

5.2.1 Infrastructure O&M Tasks

• Contractor shall maintain and monitor the SRP system environments maintained at NIH

CIT.

• Contractor shall assure the functionality of the system and make code adjustments as needed resulting from, but not limited to, the following examples: regular patching done by the FDA, or the FDA moving to more current technology.

• Contractor shall periodically refresh application/system software, database, middle tier software, security software etc. to keep current with FDA’s evolving standards.

Refreshing shall be performed within one year of the FDA establishing the next generation as a target standard.

5.2.2 Operational O&M Tasks

• Contractor shall perform operations and maintenance services in support of existing software and hardware production systems. This work shall include any development/testing/implementation necessary due to new release/changes in SRP.

Contractor shall perform operations and maintenance on the existing system and maintain necessary workflows.

• On Scheduled Maintenance Weekends at ADC (one per month):

o Contractor shall startup/shutdown so that it is not affected adversely. This includes any scheduled time between Friday at 5pm and Monday at 7am.

o Contractor shall verify system is functioning properly after bringing it back up on a maintenance weekend.

• For Unscheduled Outages at ADC (FDA does not anticipate more than 3 unplanned outages/year), Contractor shall be on call 365/24/7 to work to respond to issues within 2 hours and deploy response services within 4 hours.

• Contractor shall be primary Technical Point of Contact (POC) to ADC, WODC, NIH, ESG, EON, CVM, and any other systems that interface with SRP. The Government IT PM will be the business POC.

• When there is an event including but not limited to: scheduled maintenance and testing, Contractor shall be responsible for preparing notifications and FDA FLASH messages that need to go out when business users are impacted and other applications in the shared environment are impacted.

• Contractor shall perform patching of software for the system.

• Contractor shall manage and control configuration and changes to the system.

• Contractor shall fix/resolve new issues and existing issues documented in JIRA.

• Contractor shall install, configure, upgrade and maintain database(s). This includes updating processes, data flows, and objects (usually shown in diagrams).

• Interface with other functional areas for day-to-day checking and making corrections to applications systems.

• Contractor shall develop and perform data/database backup and recovery routines for data integrity and recoverability.

• Contractor shall create and administer regular backups.

• Contractor shall enable the system’s auditing capabilities.

• Contractor shall perform the necessary tasks to reconcile reports submitted to SRP and reports received by the target systems, and to identify and resolve the problem when reports are not reaching the target systems (i.e., missing reports).

• Contractor shall provide support that includes, but is not limited to, leading communications and problem resolution across technical staff of components of SRP to ensure successful resolution of all messaging/missing report issues for report types that flow through the system at that particular time.

• Contractor shall determine if all submitted reports to the SRP system were successfully processed and transferred to downstream destinations. If a report is not delivered to its final destination system, Contractor shall determine where issue in SRP exists and shall invoke the SRP Contingency Plan to deliver reports to destination systems within 4 hours and immediately notify the IT Project Manager (IT PM), and others as requested by the IT PM. Although FDA anticipates having a contingency option in place to manually move messages to their destination via electronic methods, that capability has not been implemented at this time. The current contingency option requires the Contractor to pick up a CD with the reports from the Contractor providing O&M support for the SRP front-end (RQ) and upload these reports into the FDA system.

• Contractor shall create and send a daily summary report of reports received and processed by the system during the last 24 hour period (specific timeframe and distribution method for the report will be communicated by the IT PM to the contractor).

• Contractor shall notify the IT PM, specified distribution list (DL) and the larger program team if operation of the system is interrupted. An example of the distribution method for this would be posting on a central communications site.

• Contractor shall lead, participate in and contribute to SRP troubleshooting workgroups that involve all components of the overall SRP system.

• Contractor shall work collaboratively with other contractors and government teams to trouble-shoot, diagnose, and document problems that prevent the end-to-end processing of reports through the SRP.

• Contractor shall perform and document root cause analysis of existing and new production issues. As this system is integrated with several other systems, the contractor shall lead a coordinated effort with other teams to troubleshoot problems. This coordination will include sharing information and collaborating on testing in order to locate and diagnose problems.

• Contractor shall perform and document a general technical review of the existing SRP system, and known issues. As part of the review, contractor shall document any new issues, and make recommendations of fixes for existing and new issues.

• Contractor shall perform configuration, security and design reviews/audits to ensure software, system, parameter, and configurations are correct.

• Contractor shall perform production control and quality control functions (e.g. job submission, checking and corrections).

• Contractor shall interface with and proactively reach out to ADC and NIH teams and SRP system component teams to help them understand activities such as: releases, maintenance, upgrades, migrations, patches, and outages.

• Contractor must be aware of the schedule for releases, maintenance, and migrations of all the components of SRP as well as the schedule for planned activities in the data centers (ADC, WODC, NIH) that may impact SRP.

• Contractor shall determine and communicate the impact that these activities may have.

• Contractor shall lead the planning and execution of contingency activities that are necessary as a result of the impacts to the SRP.

• Contractor shall identify, acquire and maintain necessary licenses for the efficient operation of the SRP. For some licenses, FDA and/or NIH staff is responsible for license purchases and maintenance. In this case, the contractor shall coordinate the license needs and maintenance with that specific group.

• Contractor shall schedule and provide training for new hires, changes in assigned responsibilities, disaster recovery, and administrators.

• Contractor shall initiate, coordinate, and execute testing of the overall SRP system.

• Contractor is responsible for leading and conducting testing efforts of the end-to-end SRP system of which it is a component, as required by the FDA EPLC for testing and validation of patches. This may include, but not be limited to: user acceptance testing, performance testing, integrated testing, and IV&V.

• Contractor is responsible for updating the Logical Data Model when changes are made to it.

5.2.3 Operations and Maintenance Related to Documentation

• Contractor shall track all defects and issues in JIRA or other tool as determined by PM.

• Contractor shall prepare and submit after-action reports for any new production issues found.

• Contractor shall update and maintain required artifacts in accordance with FDA ITIM and

FDA EPLC requirements. This shall include: updating/reviewing/finalizing/approving previously created EPLC artifacts.

• The contractor shall maintain an updated project schedule and share the schedule with members of the larger SRP workgroup.

• Contractor shall communicate status on completing scheduled tasks, particularly where dependencies exist with other teams.

• Contractor shall provide monthly status reports to include: schedule, potential project risks and mitigations.

• Contractor shall ensure all processes are documented properly in the Operations Manual.

• Contractor shall provide responses to data calls and/or Requests for Inquiries (RFI).

• Contractor shall review, update and/or create processes, create standard operating procedures (SOPs) and reports. Examples include the following: Configuration Management, Change Management and Control Procedures, Audit Logs, Backup and Restore parameters, Physical Protection, Off-site Storage Usage, Services and Availability, Output Distribution Process, System Logs and Reports, Monitoring Processes, Lessons Learned, Post Implementation Reviews.

5.2.4 Operations and Maintenance Related to Security

• Contractor shall provide responses to Request for Inquiries on security related issues.

• Contractor shall support Authority to Operate (ATO) efforts, including performing required security-related modifications as a result of ATO efforts. These modification will include, but not be limited to: applications, databases, installation procedures, software release packages, user manual/guides.

• Contractor shall perform self-administered or independent security audits.

• Contractor shall investigate and report security incidents and events.

• Contractor shall manage and document incident handling.

• Contractor shall conduct penetration testing, and create, review and approve Penetration

Test Report if required during POP.

• Contractor shall conduct vulnerability scan testing, and create, review and approve

Vulnerability Scan Report if required during POP.

• Contractor shall create, review and approve Self Assessment Document.

• Contractor shall conduct System Re-Certification and Re-Accreditation if required during

POP.

• Contractor shall update and maintain the Plan of Actions and Milestones.

• Contractor shall conduct Annual Information Security Risk Assessment if required during

POP.

• Contractor shall monitor and mitigate Information Security Risks.

• Contractor shall manage Cryptographic Keys, User Administration and Access Privileges.

5.2.5 Operations and Maintenance Related to Assessments and Reviews

• Contractor shall participate in all aspects of Contingency Planning. This includes, but is not limited to, preparing COOP plan and conducting Contingency Plan test exercises.

• Contractor shall test the Contingency and Disaster Recovery Plans.

• Contractor shall review, update and approve the Contingency Plan/Disaster Recovery Plan

Test Report.

• Contractor shall conduct the Annual System Operational Review, if required during POP.

• Contractor shall create, review and approve the Annual System Operational Review

Package, if required during POP.

5.2.6 Service Level Agreements

O&M Support Task Area

Operations Management

Weekend/Holidays CIT Updates 24x7 Monitoring Monitoring of system weekend/holidays

Maintenance & Technical Support

Weekend/Holidays Daily Reporting Updates/Evening Hours/Weekends Weekend User Support Proactive Monitoring & User Support

5.2.6.1 Communications

• At all times (24 hours per day, 365 days per year) the Contractor program manager, or designee, must be available (on-site or by cell phone and e-mail) to address FDA operational shutdowns or emergencies.

• Contractor shall provide the COR with Emergency Point of Contact information such as cell and home phone numbers. Emergency responses after business hours will be determined on a case by case basis by the FDA/CO, by the COR, or by the Technical POC.

• Contractor shall notify the COR, Technical POC, IT PM, specified distribution list (DL) or distribution method (e.g., posting on a central communications site), and the larger program team if operation of the applications/systems is interrupted.

• Initial notification for severe or widespread impact problems shall be within 30 minutes during normal business hours. Within 4 hours during non-business hours.

5.2.6.2 Support

• Contractor shall provide all developer activities to support the reliable availability of production applications as defined above.

• Contractor shall respond to production system outages 24 hours per day, 365 days per year, except as specifically defined.

• In cases where messages submitted into the SRP do not arrive at their intended destination, Contractor is to conduct troubleshooting/resolution and communicate with other SRP system technical personnel. If Contractor is unable to process messages to intended destination within 1 hour of problem notification, Contractor shall provide workaround to place message into intended destination within 3 hours. The current Contingency Plan for message delivery includes picking up the message on a CD from the Rational Questionnaire Contractor and loading the message into the FDA Sharepoint site for Business Representative to retrieve.

• Maintain an experienced Level 2/3 Technical support team including development and testing staff to ensure prompt resolution of technical issues especially related to SRP application and its run-time environment. In the case of critical issues, the Level 3 SRP Application Maintenance team should be consulted to ensure appropriate technical approach for the corrective actions.

O&M Support Hours of Operation

Help Desk – Level 1 10 Hours Weekdays (MTWThF) and as needed Level 2 – Technical 8 Hours Weekdays (MTWThF) and as needed

Support

Level 3 – Application 8 Hours Weekdays (MTWThF) and as needed Maintenance

O&M Technical Lead 8 Hours Weekdays (MTWThF) and as needed

5.2.6.3 Level 1 Help Desk

The SRP consists of several virtual servers and physical servers that constitute the production and staging environment in NIH CIT data center. These servers run Microsoft OS and components and require comprehensive systems support for the released applications running in the production environment. The Help Desk (Level 1) provides application level technical and operational support for the SRP production and staging (pre-production) environments.

Responsibilities for Level 1 Help Desk support include the following:

o Manage Level 1 support team (Help Desk) responsible for receiving and documenting initial defect or issue report from customer/user, internal QA staff, or SRP stakeholders.

o Provide direct customer/user support on technical and password issues using a help desk support system.

Help Desk personnel monitor alerts and issues generated in the SRP production

/ staging systems, SRP mailboxes, SRP development, and SRP stakeholder communities.

Support technicians are responsible for initiating prioritized tickets in the SRP Problem Tracking System for all issues.

Support technicians send an acknowledgment email with the ticket id within two hours during the hours of operation.

The initial response includes the known solutions already documented in the SRP FAQs (on-line in the SRP site), SRP knowledgebase, or release notes. If the answer is not known or the solution need administrative privileges (e.g. user account related issues such as activation, password), the technician tries to reproduce the issue in the CIT staging system and escalates an updated ticket to the Level 2 Technical Support team.

In addition, support technicians record the user comments and feedback in a database and create summary reports to be analyzed by the O&M Project Management and Business stakeholders. This analysis could for example create new requirements for the SRP.

o Update regularly the SRP knowledgebase to increase Help Desk capability of initial responses.

o Create trending reports of user request frequency and problem types (per hour, weekday and month).

o Suggest and initiate proactive actions based on frequency of occurrence of some problem types, for example mass mailing to users who did not activate account after registration, because some confirmation email that follow to activate account are filtered by anti-spam software.

o Provide Help Desk status in a weekly O&M status meeting with FDA.

5.2.6.4 Level 2 Technical Support

Level 2 Technical Support is responsible for monitoring and tracking of new issues resulting from the system monitoring activities. The technical issues are diagnosed by the team on the CIT staging system and determine a fix or work around for the issue. For fixes involving administrative privileges on SRP systems, such as activating account on behalf of user, retrying a failed transmission, etc., the fix is applied as soon as possible.

The Level 2 team consists of the development staff familiar with the SRP application and must be able to debug and identify the root cause of the reported issue. For issues that require code change or application configuration change, the Technical Support team determines if a work around can be provided with no or very localized change to code or configuration. If there is no work around or if the issue is critical (application unusable, system crash, affecting several users) or the issue is prioritized by O&M Management, an emergency fix is provided. Technical Support also calls and coordinates with the technical support team of the COTS software vendor, if needed.

If the issue is not critical or the fix involves multiple components within the SRP, the issue is escalated to the O&M Management with the recommendation to be tracked and fixed for the next release or service pack.

Responsibilities for Level 2 Technical Support include the following:

o Monitor the SRP production and staging environments on 24x7 basis for SRP alerts and notifications and respond to take appropriate corrective actions to ensure that the SRP application is functional and operational at 99.9% availability. The environments contains ten (10) servers organized as two (2) strings of five (5) servers as described in the attachment entitled “SRP Infrastructure at CIT”.

o Provide SRP application and application server administration including monitoring of the resources such as memory, disk space, CPUs, network capacity, performance, and application backup and recovery o Provide system administrative services for the virtual servers and the physical servers.

o Coordinate with CIT technical and management staff to schedule operating system and application patches and updates to minimize system downtime.

o Coordinate with NIH CIT staff to schedule emergency system patches and upgrades.

o Monitor system capacity and system performance and take corrective actions to resolve any issues in a timely manner o Coordinate with COTS vendors and apply patches and upgrades (this is done by CIT, but needs to be verified; periodic and ad hoc patches) o Provide SRP customer support and issues management requiring Level 2 Support team o Coordinate with various downstream systems including FDA’s ESG (Electronic Submission

Gateway) that receive the submitted safety reports to ensure that guaranteed delivery of all submitted data is maintained.

o Track and manage SSL certificates with NIH and FDA in coordination with ESG stakeholders.

o Maintain SRP development, testing and integration environments at the team’s facility. The

SRP development environment is used for all SP and application patch development, testing and integration.

5.2.6.5 Level 3 Application Maintenance

Level 3 support is responsible for any and all maintenance lifecycle activities for the SRP. These responsibilities include requirements collection and documentation, software design, development, implementation, integration and testing, user and system documentation development applicable to ongoing application maintenance.

Responsibilities for Level 3 Application Maintenance include the following:

o Monitor, maintain, and manage the SRP and correct defects as they become known. The same software engineering best practices and techniques used for new system development are used for application modification. All data and programming standards are used and consistently applied.

o Develop, test and apply emergency patches – NOTE: An emergency patch is an informal fix for a critical defect in the production system. A patch does not redefine the application baseline o Develop, test and release regular Service Packs (SP) – NOTE: A Service Pack (SP) is formal release of one or more patches. A Service Pack (SP) defines a new application baseline. A Service Pack does not cover new requirements or enhancements.

o Provide comprehensive database management administration support services for MS SQL Server installed in a clustered environment o Develop application fixes to the reported defects in the areas such as user security administration, auditing, backup/restore, load-balancing, capacity management, performance management, and system diagnostics.

o Participate in the EPLC Validation and Deployment Phases of DME tasks to accept the new SRP or RQ releases into the O&M Phase.

5.2.6.6 Performance Improvement

• Contractor shall monitor application performance and shall fix performance problems identified by the FDA.

• Contractor shall collaborate with the FDA business managers to identify and implement improved processes and performance of the production systems.

5.2.6.7 Expected Hours of Application Availability

Availability of the production applications is expected to be 24 hours per day, 365 days per year.

5.2.6.8 Maintenance Windows

Scheduled maintenance work shall be performed after primary business hours and/or on holidays to prevent disruption.

5.2.6.9 Escalation Procedures

If problems and/or emergencies affecting availability arise, the order of escalation is

• COR

• Appropriate functional business owners

• IT System Support

• Help Desks (ERIC)

5.2.6.10Deliverables

Task Deliverable Due Date / Frequency

Update/New

Level 1 Help Desk Automated Help Desk System using FDA approved software

Upon Award N/A

Level 2 Technical Support

Fixes, Patches

Level 3 Application Maintenance

Patch and Service Pack Deployments

As required N/A

EPLC Artifact Updates As required Update

O&M Management ICSR Report (to all SRP stakeholders)

Daily Update

Monthly Contract Status Report

Monthly (15th day of the month)

Update

Monthly Helpdesk Metrics Report (# of tickets open/closed, support issues, deployments, # reports received)

Monthly (5th day of the month)

Update

Monthly Operations Report (includes user account requests)

Monthly (5th day of the month)

Update

Quarterly Program Review Quarterly Update

Team Organization Matrix

Personnel roles and responsibilities log

Upon Award and as needed

Update

Meeting Preparation Agendas, meeting materials (documents and presentations)

24 hrs prior to meeting

N/A

Meeting Minutes Documented meeting notes and action items

48 hrs. after meeting

N/A

Data Management Sharepoint, PPM tool, etc As required and scheduled

Update

Project Process Agreement (PPA)

EPLC Artifacts As required and scheduled

New

Stage Gate Preparation and Execution

EPLC Artifacts As required and scheduled

Update

Lessons Learned Documents and Repository

EPLC Artifacts As required and scheduled

New

Release Test Plan EPLC Artifacts As required and

New

Test Cases Specifications

EPLC Artifacts As required and scheduled

New

Software Maintenance Plan

EPLC Artifacts As required and scheduled

Update

Contingency and EPLC Artifacts As required and New

Disaster Recovery Plan scheduled

Version Description Document (VDD)

EPLC Artifacts As required and scheduled

Update

Section 508 Compliance Test Report

EPLC Artifacts As required and scheduled

New

User Acceptance Test Report and Sign-off

EPLC Artifacts As required and scheduled

New

Update Operations and Maintenance (O&M) Manual including runbook for ADC and NIH

EPLC Artifacts As required and scheduled

Update

Post-Implementation Review (PIR) Document

EPLC Artifacts As required and scheduled

New

Processes, SOPs and Reports Updated

Account Management procedures, etc.

As required and scheduled

Update

Information System Interconnection Security Agreements and Memorandums of Understandings/Agre ements

Security agreements and documents between FDA and NIH and ADC

As required and

Update

5.3 DME

5.3.1 Introduction

The scope of the DME support is to obtain all services necessary to develop new and updated features of the SRP (e.g., SRP User Interface, Application Server, new message formats, routing, etc.) and the generation of new or modified rational questionnaires. This includes the implementation of EPLC specific system life cycle activities necessary to design, develop, and deploy an SRP system that collects and submits the required data elements to the appropriate backend databases in the required manner determined by FDA. In addition, requests for changes or new requirements from one stakeholder must not adversely impact other stakeholders. This requires change control management and design coordination with the stakeholders to ensure that the changes are acceptable to all stakeholders.

Participation is also required in discussions regarding all phases of the software development lifecycle to ensure adherence to FDA/NIH standards, such as the HHS FDA EPLC and Section 508 of the Rehabilitation Act.

5.3.2 Spanish Language Translation Task

The objective for this SRP Spanish language translation requirement is to provide a mechanism by which Spanish-only speaking individuals have the ability to provide Adverse Event and Product Problem reports to the FDA utilizing the SRP.

At the highest level, this task will support all activities leading to the point where the FDA Spanish language translation of the SRP shell is deployed into Production.

The purpose of this requirement is to develop a Spanish language translation of the SRP shell, for a future CTP requirement which requires translation of the Rational Questionnaire’s (RQ’s) which consists of data-driven smart questionnaires, allowing reporters to quickly submit highly structured data to the appropriate reporting system of the FDA. The SRP RQ uses a harmonized set of data elements and associated attributes defined in a pre-defined unified data model. The unified data model enables support of multiple types of RQs through the SRP. The performance of this step is necessary prior to translating individual RQ’s into Spanish.

The contractor shall engage CTP and OIM as required to conduct the following tasks to deliver the implementation of the Spanish translation of the global pages. The contractor shall participate in discussions regarding all phases of the software development lifecycle and adhere to FDA standards, including working with downstream systems and respective teams as required. The associated changes to the FDA system shall be consistent with FDA’s Information Technology (IT) standards and the FDA mission and strategic goals.

The contractor shall provide an accurate, idiomatic translation of the SRP shell into Spanish to ensure that the SRP Shell consists of all portions of the SRP in which a user may access prior to beginning a Rational Questionnaire (also known as Global Pages - See Purpose Statement Above).

The SRP Shell includes the main SRP website landing page and its links which are called the “About the Portal”, “Safety Report Directory”, “FAQs”, “Related Links”, and “Contact Us” pages.

Additional links from the landing page will also require translation, such as: “find out where to submit your report”, “Forgot your password?”, and any other links which bring users to general SRP informational pages.

5.3.3 Requirements and Design Phase Task

The contractor shall collaborate with the designated CTP Office of Science staff to develop the data specification document for the FDA Spanish language translation of the SRP shell.

This collaboration will produce a System Requirements Specification document (SRS) and System Design specification (SDD) documenting the final set of data elements, formats, dependencies, etc. The requirements gathering and analysis for a business need or an RQ is facilitated through joint application design (JAD) sessions with the stakeholders. The JAD sessions will provide the forum to review and approve the user interface design components, data specifications, business rules, and data mapping requirements.

5.3.4 Product Development and Testing Phase Task

The contractor shall provide all services required to support the successful development of the FDA Spanish language translation of the SRP shell including coding, testing, and publishing the new portal shell in the SRP staging system, based on the results of the requirements and design effort and according to FDA IT standards. Before proceeding to development successful completion of the development readiness review is required.

5.3.5 Implementation and Deployment Phase Task

This phase requires the conduct of EPLC specified testing procedures to determine whether the SRP system or RQ is ready for implementation. A Test Plan will be developed and cooresponding test cases to address both functional and use case testing will be defined and documented.

Regression testing is also performed during final testing prior to deployment to ensure the entire system is functioning properly.

Upon the contractor publishing the new report in the SRP staging system, FDA CTP shall be able to participate in the testing of the new report through the two phases as follows:

• Beta Testing Phase

5. During this phase, FDA CTP shall be able to test the shell to make any adjustments to critical areas such as Question Stems, Labeling, Frequently Asked Questions (FAQ), Online Help, or Business Rules. The contractor shall provide End-to-End testing to synchronize SRP with the downstream system as required.

• User Acceptance Testing (UAT) Phase

6. The contractor shall ensure that this phase validates agreed-upon changes between the Government and the contractor done during Beta Testing.

The contractor shall support user testing and acceptance activities designed to lead to approval from the FDA Stakeholders and Project Manager to deploy the FDA CTP Spanish language translation of the SRP shell into the production environment.

Upon successful completion of the Implementation Readiness review the contractor shall create and/or update the System Security Plan, applicable SOP’s, Version Description Document (VDD), current-state diagrams and any other documentation from earlier phases to align with the delivered system as required by the EPLC and/or FDA.

5.3.6 Technical Project Management Task

The contractor shall provide a technical manager to serve as a single point of contact for all SRP Enhancement and Maintenance technical issues, project management, and resource management. Specifically, the contractor shall coordinate, develop and update project management artifacts as required by the Project Performance Agreement per the deliverables defined in the base contract, and shall develop task plans, work breakdown structures, and Project schedules; update the schedules and report on task completion as needed; and provide a monthly status reports.

5.3.7 Deliverables

All deliverables shall be provided to the COR in electronic format (MS Word compatible or Microsoft Project, as applicable), according to the delivery schedule below.

The contractor shall meet with the CTP and OIMT management to assess progress to date, identify and review any risks and discuss possible mitigations, and determine whether the task is ready to move forward to the next phase.

The deliverable schedule shall not be changed without prior written authorization from the COR.

Task Format

Due date Deliverable

Kick Off Meeting Electronic Word Document within 2 weeks of award date

Meeting Summary Report

Project Schedule Microsoft Project within 2 weeks of Kick Off Meeting

Project Plan Document

Spanish Language Translation

Electronic Word Document within 3 weeks of the Kick Off Meeting

Technical Specification Document

Requirements and design Phase

Electronic Word Document

To be completed within 5 weeks from kickoff meeting

Report Specifications and System Design Document Development Readiness Review

Development Phase

Electronic Word Document

To be completed within 6 weeks from Requirements and Design activity

Interface Control Document Test Plan/Analysis Report Implementation Readiness Review

Implementation Phase

Electronic Word Document

To be completed within 4 weeks from Development activity

Version Description Document System Security Plan (Update) Standard Operating Procedures (Update) Test Analysis Report (UAT Revision) Deployment Readiness Review

Technical Project Management

Electronic Word document

Ongoing through the end of the

POP

Task Plan Weekly status reports Meeting agendas and minutes as needed

Monthly Contract Status Report

6 Key Personnel

The following are designated key personnel for this contract. The contractor shall propose appropriate labor categories for these position(s):

• Program Manager

• Technical Director

• Operations & Maintenance Technical Lead

• Requirements Lead

7 IT Security

For the components deployed at NIH CIT, the Contractor shall update the system security plan and complete all NIH CIT security requirements including scanning and penetration testing for the system. http://cit.nih.gov/

8 Period of Performance and Type of Task Order

This is a firm fixed price task order with a period of performance not to exceed 9 months (NOT 12 months) from the date of award.

9 Place of Performance

Contractor staff shall be…