RFPAttachment3FAERsIIDMESOW.pdf

FDA-SOL-18-1192468 Page 1 of 42 RFP Attachment No. 3: FAERS II DME Statement of Work (SOW)

Food and Drug Administration

RFP Attachment 3

CENTER FOR DRUG EVALUATION AND RESEARCH (CDER) & CENTER FOR BIOLOGICS EVALUATION AND RESEARCH

(CBER)

Pharmacovigilance System Implementation and Development Modernization and Enhancements (DME) of

FDA Adverse Event Reporting System (FAERS) II

FAERS DME Statement of Work

FDA-SOL-18-1192468 Page 2 of 42

Table of Contents

1. BACKGROUND

1.1 OBJECTIVES

1.2 SCOPE

2 SPECIFIC REQUIREMENTS

2.1 TASK AREA 1 – CONFIGURATION AND INSTALLATION OF PHARMACOVIGILANCE SOFTWARE COMPONENTS

2.1.1 A) ArisGlobal LifeSphere Modules or Equivalent:

2.1.1 B) RxLogix PV Reports and PV Signal or Equivalent Implementation

2.1.1.1 Technical Environment Provisioning

2.1.2 Software Framework Development, Integration, Implementation and Deployment

2.1.3 Initiation And Planning Build/Sprint 0

2.1.4 Modular Builds/Sprints

2.1.5 Configuration, Development, and Implementation

2.1.6 System and Integration Testing

2.1.7 Finalization Modular Builds/Sprints

2.1.8 User Acceptance Testing (UAT) Support

2.1.9 Training Support

2.1.10 Systems Integration Support

2.2 TASK AREA 2 – TRANSITION OF LEGACY SYSTEM TO NEW COTS PHARMACOVIGILANCE SOFTWARE

2.2.1 User Transition

2.2.2 Data Migration

2.2.3 Initial Data Migration Task

2.2.4 Additional Data Migration Tasks

2.3 TASK AREA 3 - TASK ORDER PROJECT MANAGEMENT

2.3.1 Project Management

2.3.2 Project Management Plan (PMP)

2.3.3 Monthly Progress Reports

2.3.4 Work Breakdown Structure (WBS) and Project Schedule:

2.3.5 Weekly Project Status Reports

2.3.6 Earned Value Management

2.3.7 Final Report

2.3.8 Communication Management

2.3.9 Escalation Procedures

2.3.10 Quality Management

2.3.11 Meetings

2.3.12 EPLC Support and Documentation

3 DELIVERABLES

4 PERIOD OF PERFORMANCE

5 PLACE OF PERFORMANCE

6 CONTRACT TYPE

7 PERFORMANCE MANAGEMENT

8 CONTRACT ADMINISTRATION DATA

8.1 CONTRACTING OFFICER’S REPRESENTATIVE (COR)

FDA-SOL-18-1192468 Page 3 of 42

8.2 GOVERNMENT POINTS OF CONTACT

9 GOVERNMENT FURNISHED EQUIPMENT/GOVERNMENT FURNISHED INFORMATION

10 LIST OF APPENDICES

10.1 APPENDIX 1: CURRENT ADVERSE EVENT AND PRODUCT QUALITY ENVIRONMENT

10.2 APPENDIX 2: FAERS II FUTURE CONCEPTUAL FRAMEWORK

11.1 APPENDIX 3: ACRONYMS

FDA-SOL-18-1192468 Page 4 of 42

Introduction

1. Background The purpose of this task order is to implement a new Commercial-Off-The-Shelf (COTS) Pharmacovigilance software product to support the collection and management of Adverse Event Reports (AERs) and Product Quality Defect Reports (PQDRs).

The FDA Adverse Event Reporting System (FAERS) system is a mission critical system for FDA for the management of AERs. The existing FAERS is a COTS tool implemented in 2012 and enables the FDA to manage consumer, health care professional (HCP) and industry submitted adverse event reports (AERs) concerning Center for Drug Evaluation and Research (CDER) and Center for Biologics Evaluation and Research (CBER) regulated products. It is composed of case management workflow functions, management reports, dictionaries, query module, batch printing, an interface to the Electronic Submission Gateway (ESG) and the Safety Reporting Portal (SRP) both for electronic submission of AERs to FAERS from industry.

The FAERS system is maintained by CDER’s Office of Surveillance and Epidemiology (OSE). The FAERS data gathered are made available internally to FDA and externally to the public through Freedom of Information Act (FOIA) requests and quarterly data extracts. The AERs processed via FAERS are then moved to a Business Objects data warehouse through a nightly batch process. CBER/CDER reviewers perform analytics, signal detection and statistical analysis against FAERS data using Oracle’s Empirica Signal software and other business intelligence tools.

Both CBER and CDER need a pharmacovigilance COTS product to be named the FDA Adverse Event Management System II (FAERS II). FAERS II will replace the current FAERS (referred as legacy FAERS throughout this Task Order) and the product quality systems Tracktor and DQRS, which supports CBER and CDER’s current needs for AE and Product Quality Defect Management (PQDM). FAERS II will provide improved usability, data standardization capability, and reduced operations and maintenance costs. This product shall become the primary source of electronic submission and processing of CDER and CBER product for pre-market and post-market AERs, PQDRs both from industry and the public.

The current design of the legacy FAERS, Tracktor and DQRS tools are expensive to maintain or modify. The existing tools do not fully comply with FDA’s security standards and policies. The application’s user interface (UI) is not user friendly, and is inefficient in case processing. These existing tools lack features offered by modern pharmacovigilance COTs applications, such as acceptance of International Council of Harmonisation (ICH) E2B R3 XML, backward and forward compatibility with ICH E2B standards, robust and automated data standardization, ease of configuration, flexible dictionaries, workflow management, batch export options, alerts/notifications and data entry tools like autocomplete, data redaction and spell check. As a result, only subsets of the data are clean and complete enough to be included in signal detection statistical analysis, and data cleanup is required for almost all review projects. The case processing includes activities like data entry, coding and prioritization that processes millions of reports annually.

FDA-SOL-18-1192468 Page 5 of 42

1.1 Objectives

The primary objective of this task order is to implement a COTS solution to replace the legacy FAERS, Tracktor and DQRS into one solution that will improve the quality of consumer and industry submitted adverse event and product quality defect report data; streamline and create efficiencies in business workflow processes; perform advance data analytics and signal management and, reduce overall operations and maintenance costs of the system resulting in safer use of FDA regulated products. The task order objectives are:

i. Provide FAERS II as one optimized repository to intake, capture, process and store both AERs and PQDRs that shall result is lowering case processing costs

ii. Implement, integrate, modernize, and enhance FAERS II to accommodate product quality defect report data along with adverse event data

iii. Migrate data from legacy systems to FAERS II

iv. Implement, integrate, modernize, and enhance FAERS II to perform PV Data Analytics and Signal Management

v. Provide a solution with all necessary COTS software, licenses, and full lifecycle support for the FAERS II solution that shall result in low maintenance and operation costs.

vi. Integrate with electronic sources of adverse event and product quality report data using standards along with other sources of information to receive products information and product assignments

vii. Provide data via Application Programming Interfaces (APIs) and/or Web-services to other data systems within and outside of FDA

viii. Perform project management and technical coordination for FDA FAERS II

1.2 Scope

The scope of this Task Order (TO) encompasses the full IT life cycle support (implementation and support) for the COTS Pharmacovigilance software for FAERS II. This includes activities from initiation through disposition and any required enhancements and maintenance to meet the objectives identified in section.

2 SPECIFIC REQUIREMENTS

• FAERS II must include the functionality needed to turn off legacy FAERS and improve the FDA’s pre-market and post-market product safety surveillance capabilities by providing a better method of processing ICSRs related to safety, medication errors and product quality reports, thereby improving analytics capabilities for downstream systems.

• FAERS II must include the functionality needed to turn off legacy product quality defect tools by providing a better solution that shall improve the FDA’s post-market product safety surveillance data collection and analysis capabilities by rapidly identifying significant health hazards associated with the manufacturing and distribution of pharmaceuticals for all regulated human medical products including drugs, therapeutic biologics and combination products. The system shall include workflow processing of FARs, BPDRs, Consumer Complaints and MedWatch reports, acknowledgement letters (for e.g. manufacturer letters and district letters), processing follow-up reports, accommodate a common product and manufacturer

FDA-SOL-18-1192468 Page 6 of 42 dictionary to code both adverse event and product quality defect reports, link to view inspection history and a central place for detecting product problem areas and trends requiring regulatory action.

• FAERS II will support the receipt and processing of both electronic and paper adverse event reports as well as integration with the electronic submission process to parse and load ICH E2B R2 & R3, extended R2 and R3 submissions for both pre-market and post-market ICSRs.

• FAERS II will support Data Analytics and Signal Management.

• FAERS II will be compatible with, integrate with, and fully leverage data from other systems for product assignment and product dictionary as well as up versioning of dictionaries like MedDRA and WHODD.

• FAERS II shall allow for easy, transparent and secure access to its critical functionalities and shall integrate multiple (and support multiple versions of) dictionaries of various types used for coding adverse event reporting data, e.g., medical terminologies, product names and active ingredients, product manufacturers, re-packers, labelers and distributors.

• FAERS II shall support integration with existing FLARe system and the FAERS Public Dashboard.

• FAERS II shall prepare data and have API/Web services developed using ICH E2B R3 and extended R3 standards so that other applications like data warehouse, business intelligence tools can read and extract data using these APIs/Web Services for internal and external use.

• FAERS II shall comply, at a minimum, with the following data standards:

o ICH E2B R2 o ICH E2B R3 o HL7 (in future FHIR)

Refer to Appendix 2 for the FAERS II Future Conceptual Framework and the detailed requirements listed in the FAERS II Business Requirements Document for complete scope.

The Task Order is divided into the following task areas. The details of each of the task areas below are described in later sections:

• Task Area 1 - Configuration and Installation of Pharmacovigilance Software Components

• Task Area 2 - Transition of Legacy System to new COTS Pharmacovigilance Software

• Task Area 3 - Task Order Level Project Management Support

2.1 Task Area 1 – Configuration and Installation of Pharmacovigilance Software Components

2.1.1 A) ArisGlobal LifeSphere Modules or Equivalent:

The Contractor shall install and configure the following Aris Global’s LifeSphere Modules to meet FDA requirements identified in RFP Attachment No. 4, FAERS II Requirements:

a) Module 1: ArisGlobal LifeSphere Multivigilance or equivalent module

b) Module 2: ArisGlobal LifeSphere Central Coding or equivalent module

c) Module 3: ArisGlobal LifeSphere Data Analytics and Reporting or equivalent module

FDA-SOL-18-1192468 Page 7 of 42

Specifically the proposed tool(s) shall address the following functional and non-functional areas:

• Electronic Submission

• Dictionary Management

• Case Management

• List Management

• Product Assignment

• Natural Language Processing

• Data Sharing

• Manage Reports

• Non-Functional

• System Administration

• System Integration

• Document Management

• Quality Management

• Batch Printing

• Data Redaction

• Workflow

• Alerts

Initially, the Contractor shall provide one (1) Each (EA) enterprise license with unlimited access to support 50 concurrent internal FDA users. In addition to case management and processing the modules shall be configured to process adverse event reports for product quality defect reports. The Enterprise license shall include coverage for all external submissions by industry. The licenses shall be technically compatible with all FDA environments and FAERS subsystems. The license shall include technical support, patches, upgrades, and bug fixes of the COTS tool.

2.1.1 B) RxLogix PV Reports and PV Signal or Equivalent Implementation

The contractor shall configure and implement into production RxLogix PV Reports and PV Signal or equivalent solution for Data Analytics and Signal Management on the White Oak Data Center (WODC) and Ashburn Data Center (ADC) or the FDA GovCloud. The solution shall be able to perform data mining, data discovery, signal management (Signal screening and identification, Signal prioritization, Signal strengthening and triage, Signal confirmation), reconcile safety data across sources, tailored role-based dashboard, develop and maintain canned and adhoc reports. The solution shall utilize FAERS data and any other external data source applicable (e.g.

Medline Literature, Cinical trials.gov). Currently, FDA reports reside in the Legacy FAERS data reporting repository.

In Fiscal Year 2017, Legacy FAERS had approximately 45 active queries and/or public canned reports. The contractor shall create reports with similar functions and purposes that will be available in the new FAERS II solution when it goes into Production.

The proposed tool(s) shall address the AL-Analytics functional area in the Requirements document. Initially, the Contractor shall provide one (1) Each (EA) enterprise license with unlimited access to support 500 concurrent internal FDA users. The licenses shall be technically compatible with all FDA environments and FAERS subsystems.

The license shall include technical support, patches, upgrades, and bug fixes of the COTS tool.

2.1.1.1 Technical Environment Provisioning

The Contractor shall collaborate with FDA systems administrators supporting the White Oak Data Center (WODC) and Ashburn Data Center (ADC) or the FDA GovCloud to ensure that the licenses are installed and available to the end users prior to user testing and within one month of the availability of the infrastructure for FAERS II.

The Contractor shall conduct activities to support the provisioning of appropriate hardware and software environments at FDA. To accomplish this, the Contractor shall:

FDA-SOL-18-1192468 Page 8 of 42

• Develop and Submit Request for Change (RFC), Server provisioning, Firewall Access & Load Balancer requests and Target State Diagrams for Development, Test, Pre-production and Production environments on FDA WODC and/oe ADC or the FDA GovCloud.

• Work with FDA Infrastructure and Security teams to configure system environment for each release, in all environments: Development, Test, Pre-Production, Production

Additionally, the Contractor shall support FDA resources to:

• Perform the required tasks to get the COTS software tools approved within FDA.

• Document the infrastructure requirements, including hardware, software, and security

• Define the solution architecture

• Use FDA’s REQUEST-IT system to request new technology, software, tools, and hardware for FAERS II

• Coordinate with the FDA data Center to ensure application servers are provisioned as per the capacity request (OS, Disk Space, Memory & CPU)

• Obtain an Authority to Operate (ATO) for FAERS II, updating with each production release

The Contractor shall work with business stakeholders (users responsible for different report types) and stakeholders from the FDA Office of Information Management and Technology (OIMT) to support the development and deployment of the system releases to the appropriate Data Center FDA GovCloud environments.

The Contractor shall follow established EPLC policies to ensure the implementations of these are in accordance to standards acceptable to the government. For emergency releases and corrections to production data, the Contractor shall be required as needed and/or depending on the criticality of the data usage and error deploy patches and/or fix data in multiple infrastructure environments.

2.1.2 Software Framework Development, Integration, Implementation and Deployment

The Contractor shall develop the software framework, build and test, integrate into the COTS Out-of-the-Box (OOTB) software, implement and deploy as follows:

• Provide a Project Schedule (PS) and Work Breakdown Structure (WBS) for each OOTB requirement (functional and non-functional), each configuration element, and each customization requirement as modular builds/sprints

• Plan, implement, and test all modules and components with their respective builds/sprints in accordance to the PS and the WBS

• Prepare system test scripts for the use cases, execute the test scripts and present the results to the FDA COR prior to initiating User Acceptance Testing (UAT)

• Plan and conduct UAT, specifically user test scripts.

• Submit and track modular build requests for the Development and Test Environments following FDA procedures for submission of infrastructure change requests

• Present the modular builds to users to test as they are deployed in Development and Test Environments

FDA-SOL-18-1192468 Page 9 of 42

• Any defects identified by the user during the modular build/sprint deployment in the Development and Test Environments shall be corrected in the next modular build/sprint, unless otherwise directed by the COR and/or the Project Manager.

• Create all required deployment artifacts including release notes, software builds, scripts, Version Description Documents (VDDs), deployment plans and updated Target State Diagram (TSD).

The Contractor shall share information with appropriate stakeholder to include, but not limited to: the COR, Business Stakeholders, FDA Project Manager, OIMT IT PMs, and database administrators. Such information includes, but is not limited to: full access to code, databases, and documentation while delivering integrated, cohesive business and technology services. The Contractor shall properly label all artifacts in a manner that does not restrict the government’s access and where appropriate conveys the government’s ownership of the intellectual property.

2.1.3 Initiation And Planning Build/Sprint 0

The Contractor shall utilize an Agile implementation approach to carrying out the work within this task order. The Contractor shall work with the current FAERS stakeholders, the FDA COR, and FDA Business and IT PMs to review the Contractor’s Work Breakdown Structure (WBS) and Schedule. The Contractor shall document any changes to the validated WBS and Schedule as a result of the review within four weeks, or 30 calendar days, of award. Work in the Initiation and Planning Build/Sprint 0 includes provisioning the hardware and software environments that the system will be deployed to.

Requirements and Design Activities The Contractor shall work with the FAERS II stakeholders to verify the core business requirements for each the contactor’s proposed modular build/sprints.

Within six weeks, or 42 calendar days, of award, The Contractor shall:

I. Conduct COTS pharmacovigilance tool review sessions to validate the core business requirements for each of the contactor’s proposed modules and components and document: 1) any new requirements/customizations as a result of the validation, and/or 2) any (possible) changes to the WBS and Schedule.

II. Prioritize and document all the core functional OOTB and Configuration requirements into the Requirements Specification Document for each Module/Component and its respective Build/Sprint.

III. Prioritize and document all the core functional customization requirements into the Business Requirements Document for each Module/Component and its respective Build/Sprint

IV. Deliver Requirements Specification Document and Requirements Traceability Matrix. The Contractor shall work with FDA PM and/or COR and FAERS business SME to get approval/sign-off for the requirements and shall make necessary changes, if needed

Within 8 weeks, or 56 calendar days, of award, The Contractor shall:

I. Prepare and provide the core Customization sub level requirements as use cases

FDA-SOL-18-1192468 Page 10 of 42

II. Maintain a Requirements Traceability Matrix (RTM) that includes Level of Effort (LOE) per core requirement in the BRD for each Module/Component and its respective Build/Sprint.

III. Document and maintain a master RTM of all requirements in a single document with all Modular Builds/Sprints of the application.

IV. Work with FDA Project Manager and/or COR and FDA team to establish/formalize the processes.

a. Change request governance processes to be used for requirement changes

b. Approval process for scope

V. Conduct a Requirements Stage Gate Review prior to proceeding to the implementation, integration, modernization, and enhancement. Once the Requirements Stage Gate is completed, the contractor shall begin deployment of the OOTB features, and development of Configuration and Customization items to fulfill FDA requirements.

2.1.4 Modular Builds/Sprints

The Contractor shall work with the FDA PM and/or COR and according to FDA requirements to schedule modular builds/sprints, choosing user stories to develop in accordance with change request processes developed in the Initiation and Planning Build 0.

The Contractor shall design, develop, test, and deploy the updated version of the FAERS II application per the captured requirements using EPLC. Depending on the modular build/sprint, the application shall be deployed to the FDA WODC and/or ADC environments (Development, Test, Pre-production, and Production) or the FDA GovCloud enviroment. All developed versions will be deployed to Development and Test. Versions produced during finalization builds/sprints shall be deployed to ADC or FDA GovCloud in pre-production and production.

Modular Build/Sprint schedules shall be strictly enforced. Modular Build/Sprints shall be scoped and defined for modular functional implementation based on the second or third level functional requirements provided in the validated and approved FDA Requirements document as detailed in the Project Schedule and WBS.

Change requests that occur during a modular build/sprint that only requires configuration shall be addressed in the current sprint or the immediate next modular build/sprint. Any change requests that require customization must be completed within the modular builds/sprints that include all customization requirements.

Prior to starting a modular build/sprint the Contractor shall conduct a sprint planning meeting to communicate the requirements to be fulfilled in the upcoming modular build/sprint. At the end of each build/sprint the Contractor shall conduct a module backlog update listing and communicating backlog requirements. Once a build/sprint is completed and tested the users shall be provided the opportunity to review the build/sprint and provide their assessment.

All software development shall follow FDA IT standards and best practices including EPLC requirements described in the EPLC Support and Documentation.

2.1.5 Configuration, Development, and Implementation

The Contractor shall provide configuration, development and implementation activities. Specifically, the contractor shall work within the bounds of the FDA EPLC – Agile Methodology process to document, configure, develop, test, release, and manage deliverables and software throughout the project. Work will be broken into modular

FDA-SOL-18-1192468 Page 11 of 42 componets with their respective builds/sprints, delivering a working and enhanced build at the completion of each.

Please note that Build/Sprints must be scoped and defined for modular functional implementation based on the second or third level functional requirements provided in the validated and approved FDA Requirements document.

The Contractor shall:

• Provide configuration and customization based on FDA requirements.

• Adhere to all EPLC documentation and process requirements.

• Provide version upgrades, to include new functionality and preserve customizations.

• Prepare and host design reviews for FDA program team members to review and approve the proposed design.

• Perform custom development as agreed upon per Modular Build/Sprint, - for example for interfacing with systems at FDA or management of custom dictionaries.

• Create and store logical and physical data models for configuration management of the database models.

Additionally, the Contractor shall perform the following for the Data Analytics and Singanla Management solution:

• Develop reporting capabilities to assist with identification of variances in pharmacovigilance data.

• Generate customized canned reports and dashboards according to FDA business needs.

• Implement the Data Analytics and Signal Management solution to accept and use legacy FAERS data.

• Reconfigure the data source from legacy FAERS to the new proposed FAERS II solution to the Data Analytics and Signal Management tool deployed on the existing cloudbased RAPID environment in FDA GovCloud when the full FAERS II solution is ready for production.

• The Data Analytics and Signal Management solution shall have the capabilities to integrate with most common data warehouses/data lakes (e.g. HANA, Hadoop, Business Object etc.).

2.1.6 System and Integration Testing

The Contractor shall:

• Document testing scripts and plans with sufficient detail to capture end-to-end processes and functions for detailed, thorough testing of complex business processes.

• Conduct and report findings on Unit, System, Functional, and Regression testing using automated tool sets o Provide Master System Test Plan o Prepare test scripts and use cases as required o Document and address findings for resolution

• Conduct Integration testing o Prepare integration test scripts and execute them to ensure that the integration to all the external systems connecting to FAERS II is functioning as per requirements and submit the test results.

o Troubleshoot case count discrepancies and respond to user’s questions about algorithmic

FDA-SOL-18-1192468 Page 12 of 42 assumptions in the data analytics and signal management tools

• Conduct System Performance testing o Ensure acceptable system performance per nonfunctional requirements for before and after each release.

• Conduct Section 508 compliance testing

2.1.7 Finalization Modular Builds/Sprints

The Contractor shall periodically conduct finalization modular build/sprints where functional and nonfunctional requirements are verified. The Contractor shall conduct user acceptance testing and a Stage Gate Review (SGR) with FDA stakeholders. For a description of stage gate reviews, see EPLC Support and Documentation. At the conclusion of these modules, the application will be deployed to the pre-production and production environments by coordinating with the contractor team at ADC or FDA GovCloud.

Once a module is completed the contractor shall conduct module review meeting to communicate the requirements that were fulfilled, identified issues, and plans to resolve those issues, including UAT test results.

2.1.8 User Acceptance Testing (UAT) Support

The Contractor shall, alongside the FDA Project Manager coordinate, lead, and execute the UAT effort during finalization of modular builds/sprints for the FAERS II Program. The Contractor shall be responsible for all aspects of the UAT effort and shall perform a variety of tasks including the creation/maintenance of the UAT plan, producing detailed test cases based on existing business requirements, providing subject matter expertise to all FAERS II Integrated Project Team (IPT) members.

The Contractor shall provide the following UAT activities:

• Plan activities to ensure alignment between UAT approach and other elements of the FAERS program such as implementation approaches, business needs, user requirements, informatics transitions, and evolving user roles

• Create UAT Test Plan & Strategy for each Major and Minor Release

• Prepare UAT test scripts that effectively translate project use cases into test scripts

• Lead and facilitate overall execution of the UAT plan and user testing

• Identify, report, and record UAT failures

• Verify and analyze UAT results

• Produce UAT summary reports

• Manage testing resources

• Review and provide input on EPLC artifacts related to UAT

• Test Planning - to include documenting test cases and test outcomes associated with the project and implementing strategies to ensure delivered system meets user requirements

Any bugs/defects, identified by the COR or PM as high or medium severity, found in any modular build/sprint UAT, must be resolved in that modular build/sprint, or the next build/sprint. Any bugs/defects not previously addressed, must be addressed prior to production release.

FDA-SOL-18-1192468 Page 13 of 42

2.1.9 Training Support

Provide training during the finalization of modular build/sprints to prepare users to use the FAERS II unassisted prior to UAT.

The Contractor shall:

• Design, create and deliver training courses and training materials to end users. Training shall be in-person or remote as designated by COR. Training sessions may also be recorded for later use.

• Deliver training to end-users on the COTS solution based on modules

• Develop user manuals for the different user roles supported by the system

• Provide initial and supplemental training on changes made for each major release of the system

2.1.10 Systems Integration Support

The Contractor shall integrate the current FLARe and FAERS Public Dashboard components as subsystems of with FAERS II. FLARe uses ArisGlobal LifeSphere Intake and Triage module (previously known as agTracker) software and FAERS Public Dashboard uses QlikSense software, respectively. Additionally, the Contractor shall reconfigure the data source from legacy FAERS to the new proposed FAERS II solution to the Data Analytics and Signal Management tool deployed on the FDA WODC and/or ADC or FDA GovCloud environment when the full FAERS II solution is ready for production implementation. The FDA will provide information on the Interface Control Documents (ICDs) as Government Furnished Information (GFI).

The Contractor shall attend and participate in technical meetings of other teams that interface or will interface with FAERS II, as per request by the FDA PM. The Contractor shall document and analyze interface specifications using an Interface Control Document (ICD) for systems that are integrated or will be integrated with FAERS II.

2.2 Task Area 2 – Transition of Legacy System to new COTS Pharmacovigilance Software

2.2.1 User Transition

The Contractor shall identify and document all user roles and responsibilities for the existing users to be transitioned from FAERS, Tracktor and DQRS systems to FAERS II. The Contractor shall also identify new users and assign them the appropriate roles and responsibilities and set them up in FAERS II.

2.2.2 Data Migration

The Contractor shall perform data migration, transition application system of CDER and CBER from legacy FAERS, Tracktor and DQRS to FAERS II. The migration of data should be phased for modular development to allow for testing of modules, to test assumptions, and to reduce the risk of lengthy reloads in the event of test issues and failures. Prior to the initial production release, all legacy data must be fully migrated to the new system.

2.2.3 Initial Data Migration Task

The current FAERS, Tracktor and DQRS project teams have documentation describing the data managed by the system which will be provided as GFI. This information will be reviewed further and submitted during the

FDA-SOL-18-1192468 Page 14 of 42

Implementation and Planning Build 0. The Contractor shall use this to prepare a Data Migration Plan for the migration of current FAERS, Tracktor and DQRS data to the new FAERS II. The Contractor in the initial migration of data shall first understand all FAERS, Tracktor and DQRS data fields, provide migration methodology options, and migrate the legacy FAERS data to the new FAERS II system for initial testing. The Data Migration Plan shall include at a minimum:

• Analysis and assessment of current legacy data that needs to be migrated

• Analysis and documentation of existing business rules

• Existing data structure

• Data extraction methods from existing system

• Acceptable data format for new system

• Plan to migrate existing special custom fields

• Plan to merge adverse event and consumer complaint reports from FAERS and DQRS respectively

• Proposed approach to data migration including timeline

• Data validation plan

During data migration the Contractor shall perform data clean-up activities, as necessary. The Contractor shall also account for all the data fields for different types of reports and the custom fields on every legacy system.

FAERS data is considered mission critical and thus requires protection from disclosure, alteration and loss. The adverse events and complaints entered into the FAERS system contain Personally Identifiable Information (PII) and Protected Health Information (PHI). The current FAERS System Design Document (SDD) details how the system handles data privacy.

The Contractor shall provide an overall Data Migration Report that documents mapping, migration methodology, data validation summary, test strategies and migration test results.

2.2.4 Additional Data Migration Tasks

The Contractor shall perform data migration one or more times, as necessary to test the methods and procedure of the migration and fix any issues encountered. Finally the Contractor shall perform a final migration before go-live.

The Contractor shall provide Data Migration Reports for each migration that documents mapping, migration methodology, data validation summary, test strategies and migration test results.

2.3 Task Area 3 - Task Order Project Management

The Contractor shall provide task order project management to ensure that the scope, schedule, quality, and price are monitored and controlled. The Contractor shall also ensure technical compatibility with FDA's technical environment such as Section 508 compliance, and reduction of IT security risks. The Contractor Project Manager (PM) shall provide overall task order management and assist in the following IT related management activities as they pertain to this Task Order: release, change control, configuration, and IT investment management. The Contractor shall use internal processes consistent with the FDA’s Enterprise Performance Lifecycle (EPLC) and IT standards.

FDA-SOL-18-1192468 Page 15 of 42

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

2.3.1 Project Management

The Contractor shall provide Task Order project management services necessary to plan, staff, coordinate, schedule, manage, communicate, report, and steward all tasks, activities, and deliverables throughout this task order execution.

2.3.2 Project Management Plan (PMP)

The Contractor shall provide and maintain a PMP within 30 calendar days of award that describes the technical approach, organizational resources and addresses policies, processes, procedures necessary and is inclusive of the following plans: communication approach, staffing plan, quality control, risk and mitigation management, change management, configuration management, build management, integration management, data migration and transition, deliverable management, and project milestone schedule, to be employed to meet the cost, performance, quality, schedule and deliverable requirements throughout this task order execution.

Additionally, the PMP shall include the reviewed Work Breakdown Structure (WBS) composed of the major and minor milestones within 15 calendar days of award.

The Contractor shall include the reviewed Project Schedule which shall be completed in accordance with Project Management Institute (PMI) and CMMI Level 3 standard practices, and incorporate all deliverables, EPLC milestones and stage gates as drafted in the Project Process Agreement (PPA) within 15 calendar days of award.

The PMP shall include a communication plan that identify roles and responsibilities of FDA personnel, contractors, and subcontractors and submit to the COR for approval within 30 calendar days of task order award.

2.3.3 Monthly Progress Reports

The Contractor’s PM shall provide monthly status reports on the progress of activities identified to the FDA Project Manager and/or Contracting Officer Representative (COR). Within the first 30 calendar days after contract award, the Government and the Contractor shall design and agree upon a standard reporting format. Formal monthly status reports shall be delivered to the FDA Project Manager and/or the COR in accordance with the delivery table at the time on or before the 10th of the calendar month following the reporting month. This report shall include at a minimum the following information:

• The overall progress of the project

• Progress on deliverables against the project plan

• Identified risks and issues as well as the mitigation strategy

• Accounting for deliverables

• Action items for the following period

• Any current or anticipated problems with scheduled activities

• The status of the previous month’s invoice

2.3.4 Work Breakdown Structure (WBS) and Project Schedule:

Maintain COR and FDA PM approved Work Breakdown Structure (WBS) and Project Schedule – Includes modules, components, builds/sprints, milestones, and all major deliverables; updated to indicate planned and actual start and completion dates for each.

FDA-SOL-18-1192468 Page 16 of 42

2.3.5 Weekly Project Status Reports

Weekly project status reports to COR, COR Designee, and FDA PM – Presents on-going activities, new activities, activities completed; progress to date on all above mentioned activities; problems and corrective actions taken;

risks, issues or concerns and proposed resolutions to address or mitigate them and, Government actions required.

For the weekly reports, there are two versions, one for the internal IT Team and the other for the integrated project team. Templates are provided as GFI.

2.3.6 Earned Value Management

The expected value of this task order requires the contract to have an Integrated Baseline Review (IBR) for Earned Value Management (EVM) purposes. Accordingly, the Contractor shall deliver Integrated Program Management Report (IPMR) Formats 1, 3, 6, and 7.

2.3.7 Final Report

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

2.3.8 Communication Management

The Contractor Project Manager shall identify how they intend to communicate with stakeholders by submitting a communication approach to address interactions between contractor staff, the COR and FDA Project Manager. The Contractor shall ensure that the communication approach provides contact information including names, roles and responsibilities, staff changes, and progress meeting schedules. The communication approach shall be submitted with the Project Management Plan (PMP) to the COR.

2.3.9 Escalation Procedures

The Contractor Project Manager shall escalate issues and risks related to any impediment to progress towards any deliverables defined in the Task Order. Issues and risks shall be based on the severity and probability of the specific issue or risk. The Contractor shall use the following order for escalation when reporting to FDA personnel:

• FDA Project Manager

• Task Order Contracting Officer’s Representative (COR)

• Contracting Officer

2.3.10 Quality Management

The Contractor shall provide Quality Management Plan detailing quality management activities that the contractor shall perform. Quality management activities may include, but are not limited to, establishing benchmarks for performance measurement and Service Level Agreements (SLAs), to be approved by the COR, that support the quality of tasks identified and performed in this task order; ensuring proper handling and safeguarding of sensitive data; identifying and mitigating risks; resolving issues; and adhering to processes and procedures.

http://aspe.hhs.gov/infoquality

FDA-SOL-18-1192468 Page 17 of 42

The Contractor shall develop a Quality Management Plan based on American Society for Quality (ASQ) and Information Technology Infrastructure Library (ITIL) standards. The Contractor may also be tasked to provide guidance on proper quality assurance methods related to document control, records or information activities.

2.3.11 Meetings

As an integral part of task order management, the Contractor shall prepare materials for and participate in or lead briefings, meetings, and other interactions with multiple FDA government points of contact for specific activities regarding project progress, issues, and concerns as directed by the FDA Project Manager or the COR. The Contractor shall participate in meetings in different capacities such as coordinating meetings, facilitating or leading discussions, contributing questions and answers, raising issues, risks and concerns, developing and giving presentations, and other active oral and written communications. These meetings shall include weekly status meetings, meetings based on the WBS and any other ad-hoc meeting that may be required.

The Contractor shall document the meeting minutes for all contractor attended meetings. The meeting minutes shall include all discussion points, summary, actions items and next steps and shall be provided to the COR in accordance with the delivery table no later than 2 business days after the meetings.

The Contractor shall also coordinate review meetings as directed by COR, to discuss the status, progress and any issues regarding this TO.

Representative tasks for a meeting include activities such as:

• Schedule meeting place and time

• Provide supporting information that may be required such as meeting agendas

• Ensure all necessary materials are distributed far enough in advance to allow for review

• Prepare meeting Room

• Give presentations

• Facilitate Discussions

• Summarize Discussions

• Draft meeting minutes

• Facilitate kickoff meeting

Specifically, the Contractor shall actively participate in quarterly public meetings with industry organized by the FDA in order to support the implementation of new standards for electronic reporting of ICSRs. The Contractor shall participate in these public meetings in different capacities such as coordinating meetings, facilitating or leading discussions, contributing questions and answers, raising issues, risks and concerns, developing and giving presentations, and other active oral and written communications.

2.3.12 EPLC Support and Documentation

The Contractor shall adhere to the FDA EPLC process for the duration of this Task Order. Within thirty (30) calendar days after award, the Contractor Project Manager shall provide a signed FDA EPLC Project Process Agreement (PPA) to the COR for each release.

FDA-SOL-18-1192468 Page 18 of 42

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

• Project Schedule

• Work Breakdown Structure

• Project Management Plan

• Business Requirements Document

• System Requirements Specifications

• System Design Document

• Data Model

• System Test Plan

• System Test Cases

• Requirements Traceability Matrix

• System Test Report

• Version Description Document (VDD)

• Authorization to Operate (ATO) - The Contractor shall support FDA stakeholders to identify and document security requirements associated with obtaining the Authorization to Operate (ATO) including NIST SP 800- 53 Rev. 3. As tasked, the Contractor shall document updated control descriptions for any NIST SP 800-53 Rev. 3 controls that will be impacted due to the work performed.

The Contractor shall provide technical coordination (initiating updates to EPLC documentation, facilitating build/sprint schedules, and discussions) among stakeholders and documentation management. The Contractor shall develop and provide EPLC and other documents (as appropriate) to demonstrate compliance with data quality, EPLC, IT security and other standards and constraints. The Contractor shall work with third party vendors that provide support or enhancement activities related to the COTS Pharmacovigilance system. Examples are, but not limited to database administrators, FDA business objects group, standardization data sources, and FDA personnel to ensure compliance. The Contractor shall ensure all EPLC documentation is free from typographical errors, grammatical errors and navigational problems. The Contractor shall create new documents in accordance with EPLC if there is no older version available or the older version is obsolete.

The Contractor shall use the following FDA tools for activities under this task order. Please be advised that FDA may change approved tools for these activities from time to time and contractor is expected to utilize available tools and will be notified accordingly when a change in tool is to occur:

• HP ALM for requirements management

• HP Quality Center for test cases and associated requirements

• JIRA for change requests and defect tracking

• SubVersion for release code management

• AppDynamics for performance monitoring

FDA-SOL-18-1192468 Page 19 of 42

3 Deliverables The Contractor shall provide the deliverables specified in the FAERS IDIQ. Additional deliverable specific to this task order are specified below.

PWS

Section

Deliverable Deliver To Qty Frequency/Due Date (in Calendar Days unless otherwise noted)

2.1.1 (A) Enterprisewide ArisGlobal Lifesphere Multivigilance 12-month Term Licenses for 1-50 Conccurent Users or Equivalent

COR and PM 1 EA Effective Date of Award

2.1.1 (A) Enterprisewide ArisGlobal Lifesphere Central Coding 12-month Term Licenses or Equivalent for 1-50 Concurrent users

COR and PM 1 EA Effective Date of Award

2.1.1 (A) Enterprisewide ArisGlobal Data Reporting and Analytics 12-month Term Licenses or Equivalent for 1-50 Concurrent users

COR and PM 1 EA Effective Date of Award

2.1.1 (B) Enterprisewide RX Logix PV Reports and Signal Management 12-month Term Licenses or Equivalent for up to 500 Concurrent users

COR and PM 1 EA Effective Date of Award

2.3.12 Updated FAERS II Requirements COR and PM As needed per sprint cycle

Starting NLT 10 days after award

2.1 and 2.2

Production Releases COR and PM 6 EA Every four (4) months, starting with the first Sprint cycle

Sprint Zero COR and PM 1 EA 2-3 months after award

2.1 and 2.2

Sprint Cycles (on average 4-5 Functional Areas per Sprint Cycle)

COR and PM 6 EA 3 weeks per sprint / 2-3 months per sprint cycle, starting NLT six (6) weeks after award

2.1 and 2.2

Sprint Cycle 1:

• Out of the box features and configurable items

• Analytics (Initial Setup) /

Production

• Electronic Submission

• Case Management

COR and PM 1 EA Cycle / 4 EA Sprints No later than 6 months after award

2.1 and 2.2

Pre-Production Release 1 / Analytics Production

COR and PM 5th Sprint No later than 6 months after award

2.3.12 Updated EPLC Documents COR and PM 2 weeks after Sprint 1

2.1 and 2.2

Sprint Cycle 2:

• Dictionary Management

COR and PM 1 EA Cycle / 4 EA Sprints No later than 9 months after award

FDA-SOL-18-1192468 Page 20 of 42

• List Management

• Product Assignment

• Natural Language Processing

• Data Migration from Legacy

FAERS

2.1 and 2.2

Pre-Production Release 2 5th Sprint No later than 9 months after award

2.3.12 Updated EPLC Documents COR and PM 2 weeks after Sprint 2

2.1 and 2.2

Sprint Cycle 3

• Data Sharing

• Manage Reports

• System Administration

• System Integration

• Analytics (FAERS II)

COR and PM 1 EA Cycle / 4 EA Sprints No later than 12 months after award

2.1 and 2.2

Pre-Production Release 3 5th Sprint No later than 12 months after award

2.1 and 2.2

Sprint Cycle 4

• System Administration

• System Integration

• Document Management

• Quality Management

1 EA Cycle / 4 EA Sprints No later than 15 months after award

2.1 and 2.2

Pre-Production Release 4 5th Sprint No later than 15 months after award

2.3.12 Updated EPLC Documents COR and PM EPLC documents per PPA 2 weeks after Sprint 4

2.1 and 2.2

Sprint Cycle 5

• Batch Printing

• Data Redaction

• Workflow

• Alerts

• Non-Functional

COR and PM 1 EA Cycle / 4 EA Sprints No later than 18 months after award

2.1 and 2.2

Production Release 5 5th Sprint No later than 18 months after award

2.3.12 Finalized EPLC Documents COR, PM, and stakeholders

EPLC documents per PPA No later than 18 months after award

2.3.11 Kick-Off Meeting COR and PM 1 EA Three (3) weeks prior to training

2.3 Project Process Agreement COR and PM One and Updated as

needed

Two (2) weeks prior to training

2.3 Project Management Plan COR and PM One and update as

needed

Created or updated three (3) weeks before each release

2.3 Monthly Progress Report COR and PM Monthly NLT 10 days after

FDA-SOL-18-1192468 Page 21 of 42

Table 1: Task Order Deliverables

4 Firm Fixed Price (FFP) Payment Schedule Deliverable Frequency / term Amount Enterprisewide ArisGlobal Lifesphere Multivigilance 12-month Term Licenses for 1-50 Conccurent Users or Equivalent

1x upon receipt and acceptance of ArisGlobal Lifesphere Multivigilance Licenses by FDA’s COR

TBD

Enterprisewide ArisGlobal Lifesphere Central Coding 12-month Term Licenses or Equivalent for 1-50 Concurrent users

1x upon receipt and acceptance of ArisGlobal Lifesphere Central Coding by FDA’s COR

TBD

Enterprisewide ArisGlobal Data Reporting and Analytics 12-month Term Licenses or Equivalent for 1-50 Concurrent users

1x upon receipt and acceptance of ArisGlobal Lifesphere Data Reporting and Analytics by FDA’s COR

TBD

Enterprisewide RX Logix PV Reports and Signal Management 12-month…