Attachement1PharmacovigilanceIDIQSOW.docx

Version: 1.0 Error! Unknown document property name.

16-223-SOL-0079 Page 1 of 26 CFSAN COTS Pharmacovigilance Software, Maintenance, Configurations, and Support CFSAN Adverse Event Management System (CAEMS) Attachment 1: IDIQ SOW

Food and Drug Administration

Attachment 1

Center FOR Food Safety and Applied Nutrition (CFSAN)

COTS Pharmacovigilance Software Implementation and Support

Indefinite Delivery/Indefinite Quantity Statement of Work (SOW)

FDA-RFQ-16-1163254 Page 2 of 26 CFSAN COTS Pharmacovigilance Software, Maintenance, Configurations, and Support CFSAN Adverse Event Management System (CAEMS) Attachment 1: IDIQ SOW

Introduction

1.1 Background

The CFSAN Adverse Event Reporting System (CAERS) was custom developed in 2003 and enables the center to manage consumer and industry submitted adverse event reports (AERs) concerning CFSAN regulated products, to include but not limited to foods, dietary supplements, and cosmetics. It is composed of a case management workflow application and database, and a connection to the Field Accomplishments Compliance Tracking System (FACTS), another source of CFSAN regulated product adverse event data within FDA.

The system is maintained by the Signals Management Team (SMT) in CFSAN’s Office of Analytics and Outreach. Users in several other CFSAN offices provide specialist review of each report, adding their conclusion to CAERS case records. The data gathered is made available internally to FDA and externally to the public through Freedom of Information Act requests. SMT runs signal detection statistical analysis against CAERS data using Oracle Empirica Signal software.

CAERS adds value to each AER by digitizing paper-submitted report data, assigning standard medical symptom terminology, product ingredients not included by submitters, and minor edits for readability. The system notifies the appropriate reviewer team based on the type of product in the report about each case, ensuring that CFSAN program offices and resources are only spending time evaluating those cases that pertain to their work. All cases are accessible by all users, easing the sharing of case information between users when needed. Despite these benefits, there are many areas of CAERS operations that could be improved to better accomplish public health goals and reduce costs.

Largely unchanged since 2003, CAERS is expensive to maintain or modify. As a custom developed application with years of patches and upgrades, changes are complex. The CAERS application user interface (UI) is unintuitive and inefficient. It lacks features offered by modern pharmacovigilance COTs applications, such as XML based case creation, robust and automated data standardization, and data entry tools like autocomplete 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. Data entry consumes more than $1 million annually. While a web-based public facing adverse event report submission system exists in the Safety Reporting Portal, the SRP covers only dietary supplement AERs (the only AER submission mandated by law) and there is no integration to the CAERS. Reports received through this site must still be entered into the CAERS manually, and operations and maintenance is costly.

1.2 Submission Types

Adverse event cases are created in CAERS using data in two regulatory contexts and several formats. Reports mandated by law (“mandatory” reports) are allowed to be submitted through the Safety Reporting Portal (SRP) website using the appropriate form, and on paper using the FDA Form 3500A. Requirements for mandatory reporting are described in the document “Guidance for Industry: Questions and Answers Regarding Adverse Event Reporting and Recordkeeping for Dietary Supplements as Required by the Dietary Supplement and Nonprescription Drug Consumer Protection Act“, available here:

http://www.fda.gov/Food/GuidanceRegulation/GuidanceDocumentsRegulatoryInformation/DietarySupplements/ucm171383.htm.

Voluntary reports of adverse events and product complaints come to FDA through many avenues. The signals management team receives paper reports on FDA Forms 3500 and 3500B. These come directly from reporters in the public and indirectly through FDA’s MedWatch program in the Center for Drug Evaluation and Research. Other AERs are received in much smaller volumes on non-FDA controlled forms from specialist organizations like the Consumer Product Safety Commission (CPSC) and the Drug Induced Liver Injury Network (DILIN). Many reports come to CAERS through a database link with the FDA Office of Regulatory Affairs (ORA) FACTS system. This report data is created by ORA staff taking phone calls from the public at any of their district offices throughout the country. Once processed through the FACTS workflow, data is made available to CAERS to access and create cases from. Finally, the SRP hosts a voluntary version of the mandatory dietary supplement report for use by the general public.

The FDA form 3500 can found here:

http://www.fda.gov/Safety/MedWatch/HowToReport/DownloadForms/ucm2007307.htm

1.3 Volume of Submissions

The system processed approximately 10,000 reports in 2015, continuing a trend of report volume increases of several hundred reports per year. In 2015, the major report formats received were:

CAERS currently supports approximately 50 internal FDA users in the following capacities:

Work to be completed under this IDIQ includes the implementation of a public facing report submission platform. This platform is expected to become the primary source of CFSAN product AERs from industry and the public, over a gradual adoption period.

1.4 AE Technical Environment

CAERs is hosted, deployed, operated, and maintained in a number of environments (Development, Testing, Pre-Production, and Production) in the FDA’s White Oak Data Center (WODC) in Silver Spring, MD and Ashburn Data Center (ADC) in Ashburn, VA. It is expected the replacement pharmacovigilance COTs application will also be hosted in the same environments. These environments are typically implemented using shared infrastructure technologies such as Cloud and virtual servers. Engineering tasks are performed in a “Sandbox” (proof of concept environment), development, test, pre-production, or production environments in either the FDA’s WODC or ADC facilities or through an FDA approved Cloud Service Provider (CSP).

The data centers are operated and maintained separately from this IDIQ contract. However, system and application owners, AE application contractors, must collaborate with the FDA contractor staff responsible for the data centers. Please see Appendix B - FDA Infrastructure Architecture for more information on FDA’s technical environment including the data center environments.

1.4.1 Development Environment

The Development Environment provides the Development Team with a stable working development environment with maximum privileges, and is used to perform the unit testing of code. The servers for this environment are available in a virtual environment in a Contractor supported data center at the FDA’s White Oak campus, also known as the WODC (White Oak Data Center) environment. Development and/or deployments may take place in the FDA’s data centers (WODC and ADC) or in the Cloud.

1.4.2 Test Environment

The Test Environment maintains a stable environment which is configured as closely as possible to match the Pre-Production environment. It is available on a virtual environment in a hosted data center at the FDA’s White Oak campus. The Test environment is meant to facilitate the following objectives:

· Conduct testing, including system and integration testing, which is required as part of the approval process for code release

· Conduct testing for applications that require frequent refresh of data or the code baseline

· Conduct testing and development of scripts for purposes such as load testing, integration testing, User Acceptance Testing (UAT), and the Version Description Document (VDD). VDD’s are documents and scripts which provide detailed instructions to deploy and implement systems in Pre-Production and Production environments where the development team typically has very limited and controlled access.

1.4.3 Pre-Production Environment

The Pre-Production environment is hosted at the Ashburn Data Center (ADC) and is configured as closely as possible to match the Production Environment including firewalls and other configurations unique to Production Environment. The Pre-Production environment is meant to facilitate the following objectives:

· Conduct User Acceptance Testing (UAT) and Performance Testing of applications. Typically system owners and system administrators will designate UAT user accounts that are maintained in this environment. Conduct security scans and code verification which are meant to ascertain and certify compliance with security standards and requirements.

· Perform testing of Extranet applications. This occurs because the “extranet” functionality cannot be tested in the tightly firewalled Testing environment at White Oak Data Center (WODC).

· Conduct testing, verification, and sanity checks when full and real production data is required.

· Conduct troubleshooting actions for an application which is dependent on the Production environment and production data.

· Provide a Training Environment for end users where users can work with using data and an environment which will mirror what they will encounter in the actual Production environment.

1.4.4 Production Environment

The Production environment is hosted at the Ashburn Data Center (ADC) and is typically a higher performance environment where only production applications are hosted.

1.5 AE tools and technologies

The data entered into the CAERS application is stored in the CAERS Oracle 11g Database. The supporting documents added to the case are stored in the Document Image Management System (DIMS).

Users with Data Entry role also have access to the Thesaurus Management System (TMS) Oracle Forms Application to resolve any custom symptom terms added. The TMS Forms Application is connected to the TMS Database. In the case of global symptom terms (that are Preferred Terms (PT) in the MedDRA dictionary), they are resolved automatically within the CAERS application as the CAERS DB has a DB Link to the TMS DB.

Figure 1: CAERS Application

Figure 2 - CAERS System Architecture

Figure 3 - CAERS Current State Diagram Purpose The purpose of this effort is to set up an ordering contract vehicle to purchase a Commercial-Off-the-Shelf (COTs) pharmacovigilance software and obtain necessary configuration / customization services to enhance the pharmacovigilance tool to meet CFSAN’s post marketing, surveillance, and outreach objectives.

2.1 OBJECTIVES

The objectives of this effort are to:

· Improve public awareness of AE events associated with products CFSAN regulates.

· Improve collaboration and communication between CFSAN reviewers, industry partners, and consumers.

· Reduce costs by implementing a COTs pharmacovigilance tool that is easily configured to meet end user needs.

· Improve user interface for internal stakeholders.

· Refine and automate workflows and business processes

· Reduce the amount of time required to process and review AE submissions.

· Reduce the amount of Paper Submissions.

· Implement a robust, extensible electronic submissions portal able to accept adverse event reports, product complaint reports, and other information submissions

· Effectively facilitate data sharing by integrating with other Agency AE applications and systems

· Improve the quality of CFSAN collected adverse event report data for more effective analysis activities

SCOPE

The scope of this IDIQ encompasses full IT life cycle support for the COTs pharmacovigilance software. This includes activities from initiation through disposition and any required enhancements to meet the objectives identified in section 2.1.

The IDIQ is divided into the following task areas:

· Contract Level Program Management and Task Order Management Support Activities

· Implementation of COTs Pharmacovigilance Software

· Transition of Legacy System and COTS product Implementation

· Operation and Maintenance (O&M) and Support Services

· Development, Modernization, and Major Enhancement Support Activities Description of tASK areas

4.1 task area 1 – CONTRACT LEVEL PROGRAM MANAGEMENT and task order level project management Support

4.1.1 Contract Program Management

The Contractor shall provide contract-level program management to achieve objectives and establish project plans, structures, processes, schedules, reporting requirements, communication channels, and quality control functions necessary to successfully execute the delivery, configuration, implementation, and maintenance of the COTs pharmacovigilance software throughout the contract’s period of performance and achieve the mission to streamline the use of genomic data between various groups within the FDA.

4.1.2 IDIQ Monthly Status Report

The Contractor Program Manager (PM) shall provide a monthly contract level status report (See IDIQ Appendix A for Sample IDIQ Level Status Report) to the IDIQ Contracting Officer’s Representative (COR), incorporating all tasks at a high level and their progress. The cost of reporting shall not be a direct charge to the contract. Within the first 30 days after contract award, the Government and the Contractor PM will design and agree upon a standard reporting format that includes the following information at a minimum:

· Summary status and progress of tasks by task order;

· Summary cost and schedule variances;

· Coordination activities across all tasks;

· Impact or influence of any task on other tasks;

· Impact or influence of tasks on overall FDA program;

· Significant risks to scheduled deliverables and plans to mitigate them; and,

· Recommendations for changes or additional activities to ensure that the tasks support progress on the overall records related objectives.

· Identification of shared resources between task orders and the amount of time allocated to each

4.1.3 Escalation Procedures

The contractor program manager shall escalate issues related to any impediment to progress towards any deliverables defined in the IDIQ or an individual Task Order. The contractor shall follow escalation procedures consistent with the line of command in FDA. The contractor shall follow this order of escalation when reporting to FDA personnel:

· Task Order Contracting Officers Representative (COR)

· IDIQ COR

· Contracting Officer

4.1.4 Quality Control

The contractor program manager shall provide Quality Control activities as identified in individual task orders. Quality Control activities for this contract includes but is not limited to meeting Service Level Agreements identified in individual task orders; ensuring proper handling and safeguarding of sensitive data; identifying and mitigating risks; resolving issues; and adhering to processes and procedures. The contractor will develop Quality Control Plans for individual task orders. The contractor may also be tasked to provide guidance on proper quality assurance methods related to document control, records or information activities.

4.1.5 Task Order Level Project Management

For the task orders released under this contract, the Contractor shall provide task order level project management to establish control, management, monitoring and notification mechanisms, ensuring that contracted tasks stay on track and important milestones and performance measures are met. For each task order, the Contractor shall prepare a Task Order Management Plan describing the technical approach, organizational resources, risk management, quality assurance and other management controls to be employed to meet the cost, performance and schedule requirements throughout task order execution. The Contractor shall use internal processes consistent with the FDA’s Enterprise Performance Lifecycle (EPLC) and IT standards.

4.1.6 Monthly Status Reports

The Contractor project manager may be requested to provide monthly status reports on awarded task orders to report on the progress of activities identified in individual task orders and their progress to the Task Order Contracting Officer Representative (COR). Within the first 30 days after contract award, the Government and the Contractor will design and agree upon a standard reporting format that typically includes the following information at a minimum and may be modified in individual task orders:

· Identify overall progress of the project;

· Identify and describe progress on planned deliverables;

· Account for delivered products and services;

· Identify action items for the following month;

· Identify current, scheduled, or future training or training needs;

· Provide status on technical support issues;

· Identify status of in-progress and new Change Control Requests;

· Report Configuration or customization issues;

· Report current or anticipated problems with scheduled activities;

· Identify project risks to schedule, cost, and quality and provide risk mitigation strategies;

· Address Invoice issues or concerns;

· Identify Accomplishments.

4.1.7 Meetings

As tasked, the Contractor project manager shall support regularly scheduled and impromptu formal and informal meetings including, but not limited to weekly meetings, monthly meetings, informal review meetings, and formal presentations. Depending on the type of meeting, the Contractor may be tasked with preparing materials for and participating in all required meetings to ensure that adequate information is disseminated relative to the project status, governance council, and project team reviews.

Representative tasks for meetings includes the following activities but not limited to:

· Schedule meeting place and time

· Provide supporting information that may be required to include 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 notes and/or minutes of the preceding

· Facilitate kickoff meeting

4.1.8 Documentation

The Contractor project manager shall provide documentation specific to the technical solution applied. Documentation may include software technical specifications, test scripts, configuration and installation guides to support a secure and authorized solution.

The Contractor shall work with the COR and IT PM to determine the appropriate EPLC documentation required for implementation, O&M, and DME work performed on the COTs Pharmacovigilance Software under this IDIQ contract. The Contractor shall create agreed upon documentation and submit to the COR and IT PM. Typical documents include but are not limited to (See Attachment 5: EPLC Artifacts for more detail on Agile and Waterfall methodologies):

· Project Charter;

· Business Requirements Document (BRD);

· Project Management Plan and Schedule;

· Systems Requirement Specification (SRS);

· Requirements Traceability Matrix;

· Test Planning and Reporting;

· Training Plan;

· User Manual;

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

4.2 task area 2 - Transition Activities The Contractor project manager shall provide transition-in and transition-out support to ensure both the incumbent and successor AE contractor staff has the knowledge and tools to ensure the system is operational and effectively supports post marketing, surveillance, and industry / consumer outreach objectives. The purpose of the transition periods is to receive or transfer expert knowledge, data, and artifacts that are used to support AE applications.

Representative Transition activities are as follows:

· Develop Transition-In or Transition-Out Plan to ensure full operating accountability and responsibility of the operational task order

· Understand roles and responsibilities of incumbent and successor staff

· Engage in regularly scheduled meetings

· Plan and engage in knowledge transfer meetings

· Receive or transfer all system documentation

· Receive or transfer all workflows and business process development documentation

· Transfer source codes if applicable

· Receive or transfer system administration responsibilities

· Receive or transfer current Change Requests

· Discuss change management processes and any other outstanding issues.

· Receive or transfer Government Furnished property or information

4.3 tASK AREA 3 - IMPLEMENTATION OF COTs Pharmacovigilance software CFSAN is seeking COTS Pharmacovigilance software licenses and associated maintenance. The proposed COTS solution shall meet or be capable of meeting the product features and functionalities in Attachment 9. It is anticipated the pharmacovigilance COTs product will replace the current custom development legacy CAERS application.

4.4 TASK AREA 4: DEVELOPMENT, MODERNIZATION, AND ENHANCEMENTS (DME)

The contractor shall perform DME activities to ensure the COTS pharmacovigilance Software will be effective in meeting CFSAN’s regulatory, public health, post market surveillance, and outreach objectives.

Representative DME Efforts include but are not limited to the following:

· Collecting, analyzing, and validating requirements for proposed DME efforts;

· Decomposing stakeholder DME requirements into detailed functional requirements;

· Transforming stakeholder DME requirements into a detailed system design that describes the system architecture, its components (i.e., hardware and/or software), and their interfaces;

· Ensuring that high level business requirements and associated use cases are translated for the design and development activities using appropriate tools and techniques (e.g. Use cases, site maps, module flows, wireframes, functional prototypes);

· Enhancing application to add features and functionality;

· Development of interfaces and system integration;

· Improving performance and capacity;

· Implementing new workflows and business processes;

· Automating processes;

· Evolving design;

· Modifying to be compliant with Government standards and HHS Policies;

· Modifying or enhancing based on best in industry practices;

· Updating System Documentation;

· Developing Test Plans and conducting test activities;

4.5 task area 5 - Transition OF Legacy system to COT Pharmacovigilance software It is the Government’s intent to transition CAERS to the COTS Pharmacovigilance software upon approval of project milestones, transition plan, and system requirements documentation.

Representative activities under this task area include:

· Interviewing stakeholders and collecting business requirements;

· Reviewing AE business requirements and system documentation and development of a Transition plan for decommissioning CAERS;

· Assisting customer in obtaining an Authorization to Operate (ATO);

· Conducting database migration and support activities;

· Conducting data migration and support activities;

· Providing metadata management, data integration, and data conversion support;

· Performing System design studies to ensure that the proposed plan for the AE rebuild is sound and developed in accordance with FDA standards and industry best practices;

· Conducting feasibility studies to identify risks and benefits of system integration and expansion efforts;

· Maintaining the integrity of mandatory data elements;

· Collaborating with end users to identify and develop current state (as is) and future state (to be) business models;

· Performing Business Process Reengineering services;

· Collaborating with end user to identify features and functionalities to be migrated;

· Participating in the Change Control Board process and obtaining proper approvals;

· Updating AE system architecture documentation;

· Creating new system documentation.

4.6 TASK AREA 6 – AE OPERATIONS AND MAINTENANCE (O&M) support The Contractor shall provide software upgrade and maintenance support. The contractor shall maintain the functionality, reliability, availability, performance, stability, sustainability, and security of the COTS pharmacovigilance software.

Representative Activities under this task area include:

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

· Analyzing and reporting the impact of infrastructure, software upgrades, capacity, and other changes to the CFSAN AE environments;

· Participating in the Change Management process and responding to Change Request (CR) tickets;

· Conducting System Administration activities;

· Conducting issue identification and management;

· Conducting release management;

· Developing test plans and conducting tests;

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

· Collaborating with ERIC Help Desk staff to assist with Tier 2 and 3 software issues;

· Conducting performance monitoring and tuning;

· Monitoring data quality and conducting quality assurance;

· Preparing Business Intelligence Reports;

· Providing back-up and recovery support;

· Providing data quality management;

· Providing integration and interface support;

· Providing various types of training support, to include but not limited to 1:1, web based, standard commercial training, train the trainer, and customized classes;

· System Disposition and Document Support.

· Providing technical support helpdesk services to end users

· Conduct minor configurations and changes to the system under 80 hours development time

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

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

· Providing technical support helpdesk services to end users

· Maintaining telephone support during business hours

· Tracking all technical support actions in FDA’s IT issue tracking system

· Working with FDA datacenter resources and within FDA’s processes to investigate reported issues, identify root causes, and provide solutions IT Constraints

5.1 General IT Life Cycle Support

All software O&M and DME activities will be, at a minimum, in accordance with FDA’s EPLC policies, processes, and templates found in Attachment 5 - EPLC Agile Methodology Overview for Contractors and Attachment 6 – EPLC Waterfall Methodology Overview for Contractors. The activities will follow either Waterfall or Agile methodologies based on the scope of work identified in individual task orders. The Government will provide updates to artifacts (standards, document templates, and processes) as they become available. As the EPLC artifacts are modified, the Contractor shall use the modified artifacts in all subsequent development activities. All software shall be developed in accordance with software engineering industry best practices, including the use of waterfall and agile methodologies. All software developed shall maintain existing database integrity, error handling, and graceful termination of execution for unexpected problems and not adversely impact other applications running in the production environment.

5.2 Stage Gate Review (SGR) Support

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

Place of Performance Place of performance will be identified in individual Task Orders.

Government Furnished Equipment (GFE)/ Government Furnished Information (GFI)

7.1 GOVERNMENT FURNISHED EQUIPMENT (GFE)

GFE will be identified in individual Task Orders.

APPENDIX A: idiq level status report

EXAMPLES OF REPORTS

IDIQ MONTHLY REPORT

Contract Title Contract Number Deliverable Title Date

Part 1: Umbrella or Master Contract

I. Summary of Accomplishments by Task Order

This section will include a summary of accomplishments for each Task order issued against the contract.

II. Description of Staff Changes

This section will include changes in personnel at the project management or key personnel level. Please note that all changes should be identified in the Staffing Matrix.

III. Difficulties Encountered by Task Order

This section will include a summary of problems encountered, as well as recommended or accrual solutions for each task order issued against the contract.

IV. Contract Modifications by Task Order

This section will include summaries modifications and/or technical directions issued for each task order.

V. Quality Control Compliance This shall identify quality control measure taken and / or quality deficiencies for individual task orders. The measures taken shall be accordance with the accepted Quality Control Plan.

VI. Summary of Task Order Status

Section VI will include a summary of task order status for each task order issued against the contract. It is recommended that the format include the following elements.

1. Title of Task Order

1. Task Order Number

1. Total Amount of Task Order

1. Identification of Option Periods and the amounts for each option period.

1. Title and amounts of Optional Line Items, Developmental Activities, and/ or additional work within scope

1. Amount Billed against Task order

1. Period of Performance for each task order Appendix b: FDA Infrastructure architecture

8.1 Infrastructure Architecture

8.1.1 Introduction

The Infrastructure architecture document provides a conceptual view of different FDA environments, the multi-zone architecture, and physical infrastructure components on which the FDA IT solution is dependent, including data center configuration, servers, storage, networks and end user devices. The infrastructure architecture is driven by the needs of the application, information and integration domains for computation power, data storage and network connectivity.

8.1.2 Business drivers

The Agency’s infrastructure architecture is driven by business, information, and technological considerations. The general business drivers are the following:

· Ability to support business needs – Agency focus is to implement several critical systems that will directly support its mission objectives. The infrastructure provisioned should be able to meet the minimum specifications required by these systems

· Meet or exceed performance requirements – Agency will need a fit-for-purpose technology infrastructure. Any degradation in infrastructure performance can interrupt business operations. Examples of performance requirements to be defined include: data throughput, response time for transactions, network latency, impact of geographic diversity, spikes, peaks, data volume and server load

· Support scalability requirements – As the Agency continues to evolve and grow in terms of employees, customers and suppliers the need for automation and technology solutions will increase. It is important to estimate the likely growth in the Agency business workload in the future. This will sustain the level of harmony between business needs and infrastructure capabilities. Examples of scalability requirements to be defined include: change in throughput, change in the number of users, change in the number of transactions, change in level of support, change in memory requirements, horizontal scalability and vertical scalability.

· Meet or exceed availability requirements - Infrastructure availability is crucial to maintain the business flow and productivity of the Agency. Examples of availability requirements to be defined include: system up-time, defined maintenance window, dependence on other systems, restore and reactivate procedures, alternative processes and fail-over plans

· To be compliant with all security requirements - Unauthorized access to the Agency infrastructure can harm and interrupt the business operations of the Agency and can potentially put the Agency under severe risks. Examples of security requirements to be defined include: privacy, data transmission protocols, encryption, remote access, multi-system access, password control and who assigns authorizations

8.2 Conceptual infrastructure architecture existing at FDA[footnoteRef:2] [2: ]

8.2.1 Overview of FDA data centers and application hosting environment The architecture for the FDA Development, Test, Pre-Production, and Production Environments is characterized as a “Multi-Zone” architecture with each zone separated by switches and firewalls to support application systems’ security. The first or outermost zone—the “Presentation Zone”—supports web and proxy servers. The second or middle zone—the “Application Zone”—supports business logic for the applications. The third or innermost zone—the “Data Zone”—contains database servers used by the applications. Additional “Transport Zone” and “Management Zone” network segments support routing into the data center as well as specialized network and management services such as Active Directory, Domain Name Services (DNS), Backup/ Recovery, and Monitoring. The following paragraphs describe other zoned regions.

Virtualization is a key characteristic of the FDA infrastructure architecture. This architecture leverages virtual server environments and network virtualization techniques to help the Agency operate its computing resources more efficiently. The Office of Information Management goals for virtualization are to achieve greater infrastructure cost efficiencies and to provide more agile technology support to the Agency and its business partners. In addition, the FDA requires that communications between different physical and virtual systems are established on an exception basis in accordance with FDA Security Policy.

The terms Zone, Enclave, and Core/Distribution are used throughout the following subsections and are defined as follows:

· Zone: A network boundary that provides a physical demarcation between horizontal Extranet/Intranet infrastructure components and vertical Presentation, Application, and Data infrastructure components

· Enclave: One or more virtual network segments that provide logical demarcation within a zone

· Core/Distribution: A common set of dedicated support infrastructure for a zone.

FDA infrastructure architecture zones and their respective enclaves are supported by dedicated Core/Distribution infrastructure environments, containing redundant border routers, firewall and other security devices, physical switches, and load balancers. The redundant load balancers provide Secure Sockets Layer (SSL) and high-availability support. The dedicated firewalls and other security devices provide a concentration of security services that include, at a minimum, packet and protocol filtering, information hiding, and audit logging consistent with the FDA Security Policy.

8.3 FDA core network

This section provides a high-level overview of the FDA Core Network. The FDA Core Network supplies redundant Wide Area Network (WAN) connectivity among the FDA’s White Oak Data Center (WODC) and the Contractor Hosted Data Center (ADC). This core network consists of Internet, HHSnet, and FDAnet WAN components to facilitate redundant, high-speed connectivity among the FDA’s main data centers. The components of the FDA Core Network components are as follows:

· FDA Core Network: A high-speed, dedicated point-to-point fiber optics network that connects the WODC and the ADC data centers

· Internet: A high-speed network that provides access to FDA extranet applications via the Internet, or other sources external to the FDA, including access to facilitate business functions

· HHSnet: A high-speed network that provides access to FDA applications for business partners via the Health and Human Services (HHS) network

· FDAnet: A high-speed network that provides access to FDA applications for Intranet business partners.

The following subsections provide architectural descriptions for the components that reside inside each of FDA’s main data centers.

8.3.1 Multi-Zone architecture overview

This subsection presents general architectural guidelines for all of the FDA data centers.

The FDA infrastructure architecture supports the Presentation, Application, and Data Zones and their specific access requirements and protections to support the needs for customers of each zone. Each FDA Development, Test, Pre-Production, and Production Environment employs these three zones to separate user and application connectivity for security purposes. The major drivers for the FDA infrastructure architecture implementation are to:

· Provide a reliable, standardized, secure computing environment for FDA applications

· Provide the necessary control to implement policy and requirements changes so FDA can comply with executive mandates, statutes, and regulations on a timely basis

· Enhance interaction with the FDA Development, Test, Pre-Production, and Production Environments by providing standard interfaces for entities that access FDA applications and data.

The FDA Multi-Zone Architecture consists of four main groups of Extranet and Intranet infrastructure components: the Transport Zone, Production & Pre-Production Zones, Development & Test Zones, and the Management Zone. Figure 3-2 below illustrates the zone architecture at FDA.

Figure 3-1: Infrastructure Architecture Component The Zones are comprised of Extranet and Intranet Presentation, Application, and a common Data Zone that separate user, application, and database connectivity to ensure security defense-in-depth. The common Data Zone hosts database environments that support both Extranet and Intranet Application Zone connectivity. Extranet and Intranet Application Zone-to-Data Zone connectivity leverage their respective Data Zone Core/Distribution environment for primary communications. When required, Extranet and Intranet Data Zone communications are supported via cross-connected network paths between the Extranet and Intranet Data Zone Core/Distribution environments. The use of these Data Zone cross-connects is highly restricted and is avoided wherever possible. The FDA Technical Reference Architecture (TRA) – Core Infrastructure Services Supplement, Version 1.0 provides implementation guidance for the specific Core/Distribution solutions deployed in each of the zones.

8.3.2 Presentation Zone

· The Presentation Zone is the first physical zone supported by one or more enclaves. The Presentation Zone controls how users and applications interface with FDA Development, Test, Pre-Production, and Production Environments. The Presentation Zone separates the user or end-application from the Application and Data Zones. This separation provides the first layer of security for the FDA Development, Test, Pre-Production, and Production Environments. All screen forms and Graphical User Interfaces (GUI) are located in the Presentation Zone.

· The Presentation Zone contains the web pages for Extranet and Intranet websites and all web servers. The Presentation Zone servers contain presentation logic (HTML) for websites containing static content. No application/business/database logic/processing are executed on servers in the Presentation Zone. All support applications, business logic, databases, tables, and sensitive information for the FDA Extranet and Intranet applications reside on dedicated servers in the Application Zone and the Data Zones.

· The Presentation Zone is supported by redundant load balancers to ensure high availability. Redundant, external DNS also reside in the Extranet Presentation Zone to provide name resolution for external-facing applications.

8.3.3 Application Zone

· The Application Zone resides below the Presentation Zone and contains application servers. This separation ensures that connectivity from the Internet, HHSnet, and FDAnet must traverse the Presentation Zone before connecting to the Application Zone. The Application Zone controls the operation of application-specific business functionality. These application-specific business functions include data validation, execution of business rules, calculations, manipulation of data, and control of the environment. When an Application Zone application requires information or actions from the Data Zone, the application makes the request and processes the response. Business results from the Application Zone are then returned to the Presentation Zone and formatted by the Presentation Zone for delivery to the end user or application for viewing or further processing. In addition, load balancers are available for applications that have high-availability, load-balanced traffic requirements.

8.3.4 Data Zone

· The common Data Zone resides below the Application Zone and contains all data access logic and data sources, including data warehouses and data marts as well as operational databases for applications. All information to be stored in the Data Zone comes through the Application Zone. The Data Zone interfaces with the Application Zone and is separated from the Presentation Zone for security purposes.

8.3.5 Transport Zone

· The Transport Zone is composed of router and switch infrastructure for the sole purpose of managing and controlling network traffic. The external sources of network traffic destined for FDA Development, Test, Pre-Production, and Production Environments are the Internet, HHSnet, and FDAnet Networks. Both inbound and outbound Internet, HHSnet, and FDAnet traffic are governed by discrete stacks of border routers, physical switches, and security devices. In addition, connectivity between FDAnet and HHSnet traverse the Transport Zone. All connectivity to and from the Presentation and Management Zones traverses the Transport Zone.

8.3.6 Management Zone

· The Management Zone provides network and security, monitoring, and management in support of all other Zones and also hosts redundant firewalls, security devices and physical switches. All network traffic destined for this Zone is routed by redundant border routers, physical switches, and security devices. The Management Zone is separated into functional areas that support a high level of availability, integrity, and accountability for all data center management in support of FDA applications. Security, backup, and management services for all servers in the Presentation, Application, and Data Zones are provided via an out-of-band network.

8.3.7 White Oak Data Center Architecture

White Oak Infrastructure Architecture The White Oak Data Center (WODC) provides support for the FDA’s Development & Test environments as well as Pre-Production and Production support for file and print services. Figure 3-3 below illustrates the WODC infrastructure architecture.

Figure 3-2: FDA WODC Infrastructure Architecture Each of the WODC Presentation, Application, and Data Zones, as well as their supporting enclaves, has the following characteristics:

· Core/Distribution infrastructure support that includes dedicated, redundant firewalls, switches, and optional load balancers, with the exception of the Data Zone, to ensure consistent and scalable infrastructure services for applications that are deployed into each Zone

· Separation into their own virtual server environments to ensure accommodation of their individual configuration and access needs

· Common server hardware support wherever possible for each application deployment in the Zone enclaves.

The following subsections present additional description of the functionality and architectural deployment guidelines for each of the environments depicted in Figure 7-3.

· Development & Test Zones The WODC Development & Test Zones (Zones 4 and 5 as shown in Figure 7-3), are supported by common physical server hardware where possible. Virtual server environments are provided to support application development and testing needs. The FDA has constructed the Intranet Development & Test environments (Zones 4c and 4d as shown in Figure 7-3) and will do so for Extranet Development & Test environments (Zones 4a and 4b as shown in Figure 7-3) as business needs arise.

The WODC Development & Test Data Zone (Zone 5 as shown in Figure 7-3) Core/Distribution infrastructure serves as the primary communications path to and from the Intranet Application Zone. Intranet database deployments into this Data Zone are supported by specific Intranet database server hardware where necessary.

· Production & Pre-Production Zones The WODC Production & Pre-Production Zones (Zones 1 and 2 as shown in Figure 7-3) are supported by common physical server hardware where possible. Virtual server environments are provided to support production application needs. The FDA has constructed the Intranet Production environments (Zones 1c and 1d as shown in Figure 7-3) to support File and Print services and will construct the Intranet Pre-Production, Extranet Production & Pre-Production environments (Zones 1c, 1d, 1a, and 1b as shown in Figure 7-3) as business needs arise.

The WODC Production & Pre-Production Data Zone (Zone 2 as shown in Figure 7-3) Core/Distribution infrastructure serves as the primary communications path to and from the Intranet Application Zone and the Management Zone. Intranet database deployments into this Data Zone are supported by specific intranet database server hardware where necessary.

The FDA has also designed support for a future WODC Legacy Zone (Zone 1e as shown in Figure 7-3) in the event an FDA application cannot be accommodated by the existing Multi-Zone architecture. FDA requires executive management approval from the CIO, CTO, and CISO as well as funding plans before this Legacy Zone can be constructed.

8.3.8 Ashburn Data Center Architecture

ADC Infrastructure Architecture The Ashburn Data Center (ADC), (formerly referred to as CHDC) provides support for the FDA’s main Production and Pre-Production environments. The ADC and WODC data centers adhere to the same multi-zone architecture and are scaled according to their specific computing requirements. As shown in Figure 7-4 below, the ADC is a lights-out data center facility that is managed and monitored remotely. In addition, no direct Internet connectivity is allowed to the ADC Management Zone in accordance with FDA Security Policy.

Figure 7-3: ADC Infrastructure Architecture The following subsection presents a description of the functionality and architectural deployment guidelines for each of the environments depicted in Figure 7-4.

· Production & Pre-Production Zones The ADC Production & Pre-Production Zones (Zones 1 and 2 as shown in Figure7-4) are supported by separate physical server hardware, and virtual server environments are provided to support production application needs. The FDA has constructed the Production & Pre-Production Extranet and Intranet environments to support most, if not all, FDA production application deployments. The FDA intends to utilize the Pre-Production Zone for validation of application release packages, user acceptance testing, application stress testing and other forms of operational testing prior to an application release to the Production Zone. The Production Zone hosts the FDA’s main production applications including training environments.

Each of the ADC Production & Pre-Production Extranet and Intranet Presentation, Application, and common Data Zones (Zones 1a, 1b, 1c, 1d, and 2 as shown in Figure 7-4), as well as their supporting enclaves, have the following characteristics:

· Core/Distribution infrastructure support that includes dedicated redundant firewalls, switches, and optional load balancers to ensure consistent and scalable infrastructure services for applications that are deployed into each Zone

· Separate physical server hardware support each Zone

· Separation into their own respective virtual server environments to ensure accommodation of individual performance, configuration, and access needs

· Common server hardware support wherever possible for application deployments into each of the Production & Pre-Production Zone enclaves.

Each of the ADC Production & Pre-Production Extranet and Intranet Data Zone (Zone 2 as shown in Figure 7-4) Core/Distribution infrastructures serve as the primary communications path to and from their respective Extranet and Intranet Application Zones.

appendix C: KEY TERMS The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

Revision Date: Error! Unknown document property name.

image1.png image2.png image3.emf

Microsoft_Visio_2003-2010_Drawing11111.vsd Title

Thin Client Servlet / JSP

Business Logic & Rules

Data Presentation Tier

TCP/IP Connection Pooling

WEB (HTTP) Sever

Application Server

Da…