Attachment_1__OIMT_SRP_IDIQ_SOW_A1.pdf

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite Delivery/Indefinite Quantity (IDIQ) Statement of Work (SOW)

Table of Contents

STATEMENT OF WORK

1. Background

2. SRP System Overview

SRP System Components

Adverse Event Reports Supported

Technology

SRP Infrastructure at CIT

3. Project Scope

4. Objective

5. Task Areas

6. Task Area 1 Operations and Maintenance (O&M) Activities

O&M Work Specific Tasks:

7. Task Area 2 Development, Modernization, and Enhancement (DME) Activities

DME Work Specific Tasks:

8. Task Area 3 Program and Project Management Activities

Program Management

Meetings

Status Reporting

Project Level – Project Management (PM) Tasks

9. Task Area 4 Transition Activities

Transition-In Activities

Transition-Out Activities

10. Deliverables and Milestones

11. Project Staffing

12. Key Knowledge Areas and Capabilities

13. Inspection and Acceptance

Written Acceptance/Rejection by the Government

Non-Conforming Products or Services

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

14. Section 508 Compliance

Scope of Section 508 Testing

15. Performance Metrics & Quality Assurance surveillance Plan (QASP)

Quality Assurance

Configuration Management and Change Control

Stage Gate Review

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

STATEMENT OF WORK

1. Background The Food and Drug Administration (FDA) is responsible for protecting our nation’s public health by assuring the safety, efficacy, and security of human and veterinary drugs, biological products, medical devices, national food supply, cosmetics and radiation emitting products. The FDA also is responsible for advancing public health by helping to speed innovations that make medicines and foods more effective, safer, and more affordable; and helping the public get the accurate, science-based information necessary for proper use of medicines and foods. Analysis of product problems and adverse event and safety report information is critical to supporting the FDA mission, which is to promote and protect America’s public health. The FDA's Strategic Plan has identified and focused on four strategic goals:

• Strengthen FDA for today and tomorrow

• Improve patient and consumer safety

• Increase access to new medical and food products

• Improve the quality and safety of manufactured products and the supply chain.

The FDA Office of Information Management and Technology (OIMT) manages the information technology (IT) and other related services including technical oversight of system development processes, policies, methodologies, and management of IT infrastructure to ensure FDA has a robust IT foundation that enable interoperability across FDA and allows development of enterprise wide, multi- Center, and Center specific systems necessary to meet FDA’s mission of promoting and protecting public health in an efficient, effective, productive, and timely manner. OIMT strives to consistently meet business needs of its customers by providing services that adhere to the agency’s IT standards and policies. OIMT has well established processes for managing its IT investments, which include the CIO Council (ADCIOs), center-based IT Investment Review Boards (ITIRB), and the HHS Enterprise Performance Life Cycle (EPLC) framework. Additionally, the SRP team has an internal Principals governing entity.

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:

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

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).

2. 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.

Because SRP was initially developed as partnership between the FDA and the NIH Office of Biotechnology Activities (OBA), the public facing architecture is hosted at the National Institutes of Health (NIH) Center for Information Technology (CIT). 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.

Since the initial release in 2010, updates, additional functionality, and new and revised reports have been added incrementally in a series of patches and Service Packs. A summary of these enhancements and releases are listed below:

Enhancements & Releases since Inception

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

2011-2012 Tasks 2012-2013 Tasks 2013-2014 Tasks

•CFSAN FSMA support •SRP Service Pack 2 •CTP new RQ development

•Implement SRP Vocabulary Management System •Implement SRP CVM GL42 RQ v2 •Implement SRP Support for HL7

ICSR v3 •Implement CVM Animal Feed

RQ for SRP •Implement CFSAN Dietary

Supplement RQ for SRP

•Replace Informatica ETL messaging support •Web Services integrations with various downstream systems.

•Implement CDER Small

Pharmaceutical RQ •Implement CTP Tobacco

Product RQ and Tobacco Investigators RQ •Design & Develop new RQ

Designer tool •Implement Group Registration and User Access functions •Replace Metaphor COTS product

The OIMT Project Manager, Center stakeholders, and incumbent development vendor work closely together to initiate tasks. These tasks include development of new reports, modifications to existing reports, and system enhancements. The current SRP 1.4 production system consists of the following RQs:

• Center for Food Safety and Applied Nutrition (CFSAN) – o Human Food Safety: Mandatory RFR Reports (1005m) o Human Food Safety: Voluntary RFR Reports (1005v) o Dietary Supplement Report : Mandatory AE Report (DSRm) o Dietary Supplement Report : Voluntary AE Report (DSRv)

• Center for Veterinary Medicine (CVM) – o Pet Food Safety: Voluntary PFR Reports (1002) – PP, AE, or both o Animal Drugs: Mandatory Animal Drug Reports (GL42) – PP, AE, or both o Livestock Feed AE Report: Voluntary AE Report (LFRv) – PP, AE, or both

• Center for Tobacco Products (CTP) – o Clinical Trials AE Reports: NIH GeMCRIS AE Report – Clinical Trial AE Report o Tobacco Products & Devices: Voluntary CTP AE Report – PP, AE, or both

• Center for Drug Evaluation and Research (CDER) – o Small Pharma AE Report: Mandatory AE Report (CDER SPHR)

In 2014 the Safety Reporting Portal received and processed 3,794 reports and YTD in 2015 has received and processed 2,408 reports.

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

The Contractor shall be responsible for managing and supporting the SRP integration points so that FDA, OIMT and Business users can perform their mission critical duties. SRP interfaces with the Electronic Submissions Gateway to transmit information to the downstream applications listed below:

• FDA Electronic Submission Gateway (ESG)

• FDA Center for Veterinary Medicine (CVM) IERS and PVWorks systems

• FDA Center for Drug Evaluation and Research FAERS/eSub system

• FDA Emergency Operations Network (EON) Database

• FDA Center for Tobacco Products (CTP) Tobacco Adverse Event Reporting System (TAERS)

• FDA Center for Food Safety and Applied Nutrition (CFSAN) CAERS system

• Any other downstream data and validation systems that may be identified

SRP is a high availability/high reliability system where downtime is only permitted in the production environment during scheduled maintenances and/or release windows. The SRP currently supports 6,493 registered users and accounts and virtually all Centers within the FDA. In 2014 the O&M Help desk processed and resolved 1056 tickets and YTD in 2015 has processed and resolved 450 tickets. In the rare event of an unscheduled outage, work to resolve the outage is required on a 365/24/7 basis.

The tables below give a view of SLA activities, associated task areas, and a representation of monthly historical activity:

O&M Support Average

Help Desk – Level 1 59 Tickets resolved/month Level 2 – Technical Support 25 Issues resolved/month Level 3 – Application Maintenance 15 Issues resolved/month

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

The Safety Reporting Portal is a web-application designed to efficiently collect adverse event or safety report data to support federal-wide submission of mandatory and voluntary safety reports from manufacturers, distributors, and users of products that may result in adverse events in humans or animals. The adverse event report data is collected through data-driven smart questionnaires, also called Rational Questionnaires (RQs), allowing reporters to quickly submit highly structured

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite data to the appropriate adverse event reporting system of the Food and Drug Administration (FDA).

The SRP RQ uses a harmonized set of data elements and associated attributes defined in a pre-defined unified adverse event data model, which is based on the recommendations of the Federal Adverse Event Taskforce (FAET). The unified data model enables support of multiple types of RQs through the SRP. The SRP application is capable of transforming the collected structured data into a standard format matching the destination system format, such as the Health Level Seven (HL7) Individual Case Safety Report (ICSR), E2B(R2), or XML. The SRP system provides secure and guaranteed delivery of the data to the FDA and the National Institutes of Health (NIH) systems.

The SRP System was developed in collaboration with the NIH Office of Biotechnology Activities (OBA) and has been operational since May 2010 in the NIH Center for Information Technology (CIT) data center (http://cit.nih.gov/). 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.

The SRP was developed using Microsoft Visual Studio (.NET) and SQL Server database. In addition, several licensed commercial-of-the-shelf (COTS) products are integrated in the SRP to support various application and system features.

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.

SRP System Components

The SRP System, shown below, supports the collection of safety reporting data provided by industry, researchers and consumers through a web portal. The information is based on structured questionnaires or RQs hosted on the SRP application server. The collected data is then transformed into the appropriate messaging format and routed to the responsible organization within FDA or NIH. All adverse event report data destined for the FDA’s adverse event reporting systems is securely submitted through the FDA Electronic Submission Gateway (ESG). Each adverse event reporting system uses a custom service to fetch their data from the ESG folders into their respective backend systems for analysis.

Industry, Researchers, and Consumers

SRP Rational Questionnaire

SRP Application Server

(Metaphor)

FDA Centers

(via ESG)

NIH

Routing (BizTalk)

HL7/E2B(R2)/XML

Message

Transform

The SRP application is composed of the following integrated components:

o SRP Rational Questionnaires. The SRP Web User Interface supports pre-defined reporting situations (Rational Questionnaires) and provides the primary user interface and workflow http://cit.nih.gov/)

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite to collect the safety report data from the reporting user. The user interface consists of context sensitive questions (dynamic questionnaire), predefined business rule driven workflow, and data validation.

o SRP Application Server. The application server provides a framework to support multiple SRP RQs. It also supports core functional areas, including the framework for new reports, business rules for data and workflows, user management modules, and administrative interfaces. New RQs, constructed using the unified data model for adverse events, can be published in the SRP application server.

o Message Transform. This module transforms the submitted report data into a predefined format, such as XML, HL7 ICSR, and E2B(R2) to match the expected message format of the destination system. The input to this module is the data mapping template (XPATH) representing the destination format. The output of the message transform module is the RQ message data ready for routing o Routing. This module is capable of routing message data to a specific destination and/or multiple destinations, such as servers located within FDA centers accessible via the ESG or to servers located at the NIH.

Adverse Event Reports Supported SRP supports the following mandatory and voluntary adverse event reports:

1. Mandatory Reportable Food Registry (1005M) Safety Report (FDA CFSAN)

2. Voluntary Reportable Food Report (1005V) Safety Report (FDA CFSAN)

3. Voluntary Pet Food Report (1002) Safety Report (FDA CVM)

4. Mandatory Animal Drug (GL-42 V2) Report (FDA CVM)

5. Mandatory Gene Research Study (GeMCRIS) Report (NIH OBA)

6. Voluntary Tobacco Product Report (FDA CTP)

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

7. Voluntary Tobacco Product Investigator’s Report (FDA CTP)

8. Mandatory Dietary Supplement Report (FDA CFSAN)

9. Voluntary Dietary Supplement Report (FDA CFSAN)

10. Voluntary Livestock Food Report (FDA CVM)

11. Mandatory Marketed Human Drug and Therapeutic Biologics(SPHR) Report (FDA CDER)

Technology

The SRP server components are based on a customized COTS product and technology platform called USAN Metaphor 3.5. Metaphor supports several SRP key features mostly through its Application Server component, which is responsible for interacting with MS IIS Webserver to generate the appropriate RQ pages, sections, and controls in the browser in response to user inputs. The Metaphor Technology Platform is also used in the development of new RQs for SRP. Several other COTS products are also integrated with the SRP to support various required features such as spell checker, file uploader, calendar control, etc.

Other technologies implemented within the current SRP system for the SRP application, RQs, and related infrastructure are as follows:

o SRP Application

C# and .NET Windows Communication Foundation (WCF) - MS service oriented architecture

(SOA)

MS SQL Server; MS SQL Server Reporting Services (SSRS) BizTalk to provide message confirmation and complete (i.e., 100%) reliability Data transmission within the FDA using the Electronic Submission Gateway (ESG) and Applicability Standard 2 (AS2). This includes the transmission of a variety of data through a single, system-to-system connection using an application such as MS BizTalk (a Drummond certified product) o Rational Questionnaires

Definition of messaging formats, such as – Health Level 7 Individual Case Safety Report (HL7 ICSR v2/v3) , E2B(R2)

Standard vocabularies/dictionaries (e.g., MedDRA and VedDRA) o Infrastructure. The SRP infrastructure is located in a private cloud in the NIH Data Center as specified below.

SRP Infrastructure at CIT

The SRP infrastructure at NIH CIT includes two identical environments – one for Production System and the other for Staging System. The main infrastructure for each of the SRP systems includes:

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

1. Five (5) servers:

o Web server hosting the Portal site and the User Interface to users of the site;

o Application server running the workflows for user access and reports;

o Database server hosting SRP databases including report snapshots, user accounts, auditing;

o Transform server running conversion of submitted reports into SRP messages for transmission to FDA/NIH downstream systems. Also responsible for attachments uploaded by users;

o BizTalk server responsible of guaranteed delivery of messages to FDA’s ESG system.

2. The system is load balanced to ensure that user load is evenly distributed over multiple servers.

3. Most of the system servers are virtual servers

4. Each server in the system has a redundant active server to support a user transparent fail-over to the redundant active server. The system does not have any single point-of-failure.

5. The two SQL Server instances are on two Physical Servers in a cluster (each instance is

Active-Passive)

6. The system is scalable including storage for capacity and performance

7. The system supports a public URL for end-users to access the Portal and submit safety reports and an HHS URL that allows SRP to submit safety report data to FDA’s Electronic Submission gateway (ESG). The FDA ESG data submission requires a special port opened on the NIH CIT Firewall.

3. Project Scope The scope for the FDA SRP Application Life Cycle Support IDIQ includes planning, requirements analysis, design, development, testing, implementation, operations, and maintenance of the SRP system that integrate hardware, software, data, network, and security. It also includes providing project management, reporting, user assistance, process improvement, documentation, training and meeting support necessary to implement technical tasks.The contractor shall work within established FDA guidelines and standards. All software activities will be, at minimum, in accordance with FDA and HHSEnterprise Performance Life Cycle (EPLC) policies, processes, and templates, which include both waterfall and agile methodologies. An explanation of FDA’s implementation of the EPLC can be found in the attachment entitled “HHS EPLC Artifact Descriptions” and the following link for NIH specific policies and procedures https://enterprisearchitecture.nih.gov/Pages/EPLCandEA.aspx.

4. Objective The objective of this FDA SRP Application Life Cycle Support IDIQ is to acquire application life cycle management support and continuity of services for the FDA Safety Reporting Portal. Full application life

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite cycle support includes the integration of hardware, software, data, communication and technologies.

Specifically, the government seeks to achieve the following objectives:

• Support the development and implementation of new RQs as well as modifications for existing

RQs;

• Promote the use of HL7 standards

• Perform a migration of SRP front-end components from CIT data center to an FDA-hosted environment or other cloud hosting solution;

• Support critical needs beyond adverse event and product problem reporting such as the implementation of a structured product label (SPL) RQ.

• Develop mobile capability to support submissions from a mobile device.

5. Task Areas The IDIQ is divided into the following major task areas:

1. Operations and Maintenance (O&M) – 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.

2. Development, Modernization, and Enhancement (DME) – Includes minor enhancements such as minor user interface changes, additional data elements, new reports, business rule modifications, and small functional improvements. Minor releases are on an as needed basis and typically deployed into production during a 3- 6-month period. Also includes major enhancements or redesigns of existing software, commercial-off-the-shelf (COTS) software purchases, signification functional improvements, and third-party developed and hosted applications. Production major release (are typically delivered in 6- to 12-month cycles.

3. Program and Project Management – Specifies program- and project-level management services necessary to support the execution of the contractor’s approach to the technical activities performed under the IDIQ and to report the status to the Government.

4. Transition Activities – Ensure smooth, efficient, and orderly transition in and out of development and O&M activities for the SRP application, components, and interfaces.

The tasks and activities listed above shall be provided for the SRP system as directed by the OIMT Project Manager with input from the Center business owners. Furthermore, interaction with employees and other contractors who use and maintain the interfacing systems should be expected in order to support the various system interfaces and database links that exist between SRP and other systems.

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

6. Task Area 1 Operations and Maintenance (O&M) Activities

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.

The FDA expects that O&M Task Orders will be Firm-Fixed Price.

Specifically, representative O&M support activities for the SRP include:

o Overall System Administration, Monitoring, Maintenance, and Support of the SRP Production system running at NIH CIT.

o Overall System Administration, Maintenance, and Support of the SRP Staging system running at NIH CIT. The staging environment is a replica of the production system and is primarily used to validate a build for production.

o Overall System Administration, Maintenance, and Support of the (contractor provided) development and testing environments 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 the HHS FDA and NIH Enterprise Performance Lifecycle (EPLC) development methodology (attached).

o Overall maintenance and updates of system related documentation including system administration processes and procedures, architectural diagrams, and data models (logical and physical) where necessary.

o Provide, maintain, and operate a Help Desk system (using FDA approved tracking systems – HP Service Manager) to support user, SRP SMEs, and SRP stakeholder issue tracking and management using Help Desk management best-practices.

o 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 Maintain and manage the SRP production source code, build and install scripts, configuration items such as requirements, design, and test documents. In addition, maintain a fully functional SRP O&M Development environment to develop and test emergency patches to resolve O&M issues.

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

o Provide SRP contingency support activities as directed by the SRP stakeholders.

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite o Provide SRP O&M Support for 8 hours per day (Monday through Friday) and 4 hours on weekends and all holidays.

o Provide an O&M Team Lead as a single point of contact for all technical and management activities

O&M Work Specific Tasks:

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).

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite 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.

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

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite 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.

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.

O&M Management

This effort requires management expertise in team building, communications, time management, quality assurance/change control management, SOP development, risk management, configuration

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite management, cost management, and software integration. In this task area, representative responsibilities include:

o Provide an O&M Team Lead as the single point of contact for the O&M Support team and is responsible for the SRP operations and service levels - see attachment titled “Service Level Agreements”.

o Participate in weekly review meetings with NIH CIT technical and management staff o Provide a comprehensive monthly O&M status report covering activities, status of resources, O&M metrics and system activity summaries to the COR.

o Coordinate with FDA and CIT on SRP hotfixes/patches, service packs, and COTS updates.

o Coordinate with CIT technical and management staff to schedule operating system and application patches and updates to minimize system down time (the system is expected to be up 99.9% of the time).

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

o Develop the O&M Management Plan that identifies management strategy and goals, and revise the management plan as needed.

o Develop detailed project plans and standard operating procedures (SOPs) for various O&M activities.

o Manage change control and defect tracking policy and procedures and update them as needed.

o Manage and maintain all COTS licensed components of the system.

o Understand the overall mission of the SRP and the most efficient and effective ways to support it.

7. Task Area 2 Development, Modernization, and Enhancement (DME)

Activities The Contractor shall perform DME activities in support of SRP evolving needs. DME activities are related to development of new systems or modernization and enhancements of existing components. FDA cannot anticipate with specificity the objectives, frequency or value of the DME efforts it will need during the life of this order.

The FDA expects that DME Task Orders will be Labor Hour.

Each year, the FDA conducts IT Investment Review Board (ITIRB) meetings in conjunction with the CIO Council (CIOC). The ITIRB is comprised of business and IT leaders and is responsible for identifying, prioritizing, approving and funding IT initiatives with the approval of the over-arching CIO Council. At the ITIRB meetings, the Board approves the FDA IT budget and identifies the IT initiatives that the Agency plans to fund during the next two years. DME activities related to initiatives approved by the ITIRB will be performed under this order. Additionally, OIMT may identify other DME activities that arise due to new legislative or regulatory mandates, emerging health concerns, and shifting FDA priorities.

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

FDA/Office of Information Management/DAS will fund these ad hoc DME projects under this order.

Any DME projects that will be deployed to the production environment will be closely monitored for bug fixes and stability. Once they become stable, they will be added to the O&M list. The FDA will update the list of production systems that need O&M support.

Please refer to the following attachments for additional information:

• HHS EPLC Projects – Exhaustive List of Development, Modernization, and Enhancement tasks.

Not all of them apply to all of the projects.

• HHS EPLC Artifacts Description for the definition of the Project Process Agreement (PPA). For all projects under this contract, the Contractor shall perform the specific tasks identified in the Project Process Agreement (PPA) and project plan submitted with its proposal and maintained/updated per project requirements.

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.

DME Work Specific Tasks:

Requirements Analysis and Specifications

This phase of the task requires working with the FDA to develop and/or update the requirements specification document for any new SRP component and RQs. This effort produces a System Requirements Specification (SRS) document, which includes the user interface design specifications, business rules and data specifications. The requirements and user interface design specifications are used to develop the Requirements Traceability Matrix (RTM) and Interface Control Specifications (ICS). At the highest level, this phase supports all activities leading to the point where the development team can move forward with the implementation phase.

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 also provide the forum to review and approve the user interface design components, data specifications, business rules, and data mapping requirements.

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

Feasibility and requirement analysis is required for potential enhancements to the existing SRP system, infrastructure and its production environment.

System Design and Development

This task supports the design and development of the system according to FDA IT standards. Before proceeding to the development phase, successful completion of development readiness review is required.

At a minimum, the following activities are conducted as part of this phase:.

o Design the system enhancement or update based on the detailed requirements identified, verified, documented and approved in the SRP requirements document.

o Prototype modules and demo the prototypes to the business community for review and verification.

o Develop or update the System Design Document, including Contingency Plan, and other existing documentation that is required by the EPLC framework and/or FDA.

o Work with the Contracting Officer’s Representative (COR) and SRP stakeholders in the verification and approval of the design at designated milestones and update the PMP as necessary.

o Develop all application/system code and other deliverables required to build the system or RQ according to the System Design Document.

o Write system/application code level documentation with particular emphasis on source code documentation.

o Complete a successful Validation Readiness review in accordance with the HHS EPLC for the initiation of system testing.

Testing

This phase requires the conduct of EPLC specified testing procedures to determine whether the SRP system or RQ is ready for implementation. Regression testing is also performed during final testing prior to deployment to ensure the entire system is functioning properly.

At a minimum, the following activities are conducted during this phase:.

o Develop a Test Plan and corresponding test cases to address both functional testing and use case testing for user acceptance.

o Create/load the test data sets and databases and perform system testing to validate the design against the RTM o Document all results in applicable test reports and issue management/tracking system.

Return failed components to the developers for rework; migrate passed components ahead.

o Conduct regression testing to ensure the entire SRP system is functioning properly.

o Coordinate and communicate with other organizations to cycle the release through user acceptance testing, release management and configuration management.

Implementation During this phase, the EPLC specified implementation and post-implementation procedures are performed upon the successful completion of the Implementation Readiness review.

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

At a minimum, the following activities are conducted during this phase:

o Complete a successful Implementation Readiness review in accordance with the HHS EPLC.

o Create or update the System Security Plan, applicable Standard Operating Procedures

(SOPs), Version Description Document (VDD), current-state diagram and any other documentation from earlier phases to align with the delivered system as required by the EPLC and/or FDA;

o Deploy final release to the production environment at NIH.

o Participate in the collection, review, maintenance, and dissemination of Lessons Learned post implementation and prepare the Post-Implementation Review (PIR).

DME Technical Management The DME effort requires technical management expertise in team building, communications, time management, quality assurance/control management, procedure development, risk management, configuration management, cost management, and software integration. The following support is representative of DME activities for the SRP:

o Provide a DME Team Lead as the single point of contact for the Development Support team and is responsible for the SRP updates.

o Manage DME team in terms of time/resource allocation and task assignments o Provide a comprehensive Monthly DME Status Report covering activities, status of resources, DME schedule, and summary of major issues to the COR.

o Participate in weekly project meeting with FDA o Lead the weekly SRP DME team status meetings o Coordinate with FDA SME and technical staff to prioritize DME activities o Provide DME status input for the SRP Program Monthly Report o Coordinate, develop and update project management artifacts as required by the EPLC.

o Develop project management plans, milestones, budgets, work breakdown structures, and

MS Project schedules; update the schedules and report on task completion percentages as needed; and update the budget and report on funds spent and remaining.

8. Task Area 3 Program and Project Management Activities The Contractor shall perform project management activities necessary to support the execution of its approach to the technical aspects of this order. Program and Project Management Activities are incorporated into all Task Areas.

Program Management The Contractor shall provide overall contract level project management and qualified staff to perform work, including activities such as:

• Preparing and overseeing work plans

• Managing schedules and cost expenditures

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

• Interacting with multiple government points of contact for specific tasks regarding progress, issues, and concerns

• Reviewing program documents

• Conducting periodic progress reports

• Participating in briefings and meetings

• Preparing meeting agendas, minutes, notes, issues, and action items

• Disseminating documentation

The Contractor shall provide services in areas requiring coordination, including, but not limited to:

• Interfaces (database and project) between projects

• Conflicting stakeholder requirements

• Scheduling conflicts

• Resource limitations

Meetings The Contractor shall participate in meetings in different capacities, including but not limited to, leading discussions, contributing questions, raising issues and concerns, developing and giving presentations, and other active oral and written communications dependent on the subject matter and expertise of the contractor representatives and the needs of the government meeting members.

The Contractor and/or Contractor employees shall hold weekly status meetings with the COR, FDA/Office of Information Management/DAS IT Team, and Technical POC. During these meetings the contractor shall identify:

• Contract activities and overall goals,

• Provide a review and status of the major deliverables of the contract; and

• Discuss assumptions, risks assessments/mitigation strategies, and other issues that may impact the project.

Contractor shall provide meeting minutes following meetings containing, but not limited to, work accomplished, pending tasks, issues and constraints, and risk assessments/mitigation strategies on scheduled tasks that may affect meeting goals and timelines. The contractor shall provide written monthly reports on status, issues, and financial information.

Status Reporting The Contractor shall submit a monthly status report for each project, including at a minimum the following information:

• Accomplishments - Bulleted list of accomplishments

• Milestones - A milestone report for current month, and next 2 months, including:

• Original completion date (order milestones by original completion date)

• Actual completion date

• Issues - Issues anticipated and proposed solutions:

• In next 30 days

• In next 60 days

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

• In next 90 days

• Routine Maintenance Activities – Summary of completed trouble-shooting and problem resolution incidents or ad-hoc requests.

• Status report shall precede invoices and clearly state the work performed and how it is billed on the invoices.

• Invoices shall list all billable persons by name, number of hours worked, and labor rate.

Project Level – Project Management (PM) Tasks

The contractor shall perform project level Project Management (PM) support as required per task order for each project and operations and maintenance (O&M) activity supported under this contract. The contractor PM shall provide the following activities throughout the life of the project. These activities, include, but are not limited to:

• Objectives, scope and deliverables,

• Project structure, project schedule and budget

• Milestones,

• Systems support

• Development approach

In addition, the Contractor shall perform the following support activities, including but not limited to:

• In progress Project Meetings - During these meetings the contractor shall:

o Identify project activities and overall goals o Review and status of the major deliverables of the project.

o Discuss assumptions, risks assessments/mitigation strategies, and other issues that may impact the project.

o Schedule and conduct meetings o Prepare and distribute meeting agendas, minutes, notes, issues, and action items o Track action items

• Communication/Reporting o Monthly project dashboards in a pre-defined format o Interacting with multiple government points of contact for specific tasks regarding progress, issues, and concerns

• Documentation o Prepare all required project documentation in acdance with the EPLC and industry best practices.

o Review program documents o Maintain the project data in a designated project management system (i.e., eRoom, Clarity (PPM).

o The contractor shall make all project (EPLC, etc.) documentation available in a designated area that is accessible to the COR, Technical POC, IT PM, and Technical Leads.

Attachment 1 – Office of Information Management and Technology (OIMT) Safety Reporting Portal Indefinite

9. Task Area 4 Transition Activities

Transition-In Activities This task is to provide support services to the orderly transition of functions from this order from the successor contractor. The transition plan describes the activities and timeline by which the contractor will gain the necessary knowledge of the system and processes from the existing contractor, from FDA staff, and from others, in order to effectively assume operations and maintenance responsibilities defined in this statement of work. The Contractor submits all transition documentation to the Contracting Officer Representative for approval.

TA representative set of transition-in activities includes the following:

• Discovery and transfer of all project-related documents and artifacts, to include documents, software code, software development tools, testing artifacts, and others.

• Knowledge transfer to contractor staff from previous contractor.

• Familiarization with…