Atch_4_SERIO-SOW_-_updated.pdf

SOL18-223-SOL-00017

Amendment 2

Task 3 - System for Entry Review and Import Operations

1 Introduction

1.1 Background Information

Several mission critical systems within the FDA support FDA compliance and enforcement activities for import operations. Import Operations is one of the key functional areas within FDA.

Headquarters and field staff rely on several systems to support the processing of entries of imported FDA-regulated commodities. Entry Review (ER) and the Operational and Administrative System for Import Support (OASIS) are the primary components used by field staff to perform entry review, to record fieldwork results, and to make compliance and admissibility decisions on entries or goods submitted for import in the country. While other systems associated with the entry process are discussed below, the primary focus of this Statement of Work pertains to the development of an end-to-end system for entry review and import operations (SERIO). This SERIO system will ultimately provide for the unification of functionality currently available in ER (a Java based system using an ORACLE database) and OASIS (ORACLE Forms and an ORACLE database) to enhance efficiencies and resource utilization. SERIO will work in concert with other mission critical systems and tools used in the entry process such as eFieldX, a mobile application currently under pilot that supports collection of samples at the ports, the Predictive Risk-Based Evaluation and Dynamic Import Compliance Targeting (PREDICT) tool, which is utilized to perform risk-based screening of entries coming to FDA via an interface with Customs and Border Protection's (CBP) Automated Commercial Environment (ACE). FDA’s Import Trade Auxiliary Communications System (ITACS) is utilized to allow the Import trade community to view status of entries/lines and send documents for open entries stored in the OASIS database. Prior Notice Manager provides the staff of the Division of Food Defense Targeting (DFDT) with capabilities to review and process food imports subject to Prior Notice requirements. The On-Line Reporting Analysis Decision Support System (ORADSS) serves as the reporting database for our Import systems. ORA’s needs for these systems continue to evolve with new business requirements and the need to support an increasing volume of imports and needs for information by FDA staff across ORA and the Centers.

1.2 Objectives

The purpose of this statement of work is to complete the requirements for Compliance functionality, the requirements, development and production implementation for Notices Generation and Printing, Import Investigation Time and Input Line Availability, and implement enhancements to support Mail and Baggage functionality. This SOW supports modifications, consolidation of database objects and analyses needed to enhance the current OASIS database which also supports ER and OASIS applications to meet the needs of FDA’s headquarters field Investigational and Compliance staff in performing increasingly demanding duties related to processing imports. These enhancements include changes to the database and development and implementation of workflow application/ application modules to update current systems to meet the increasing performance needs and enhance functionality in response to increased requirements. The system to be developed, System for Entry Review and Import Operations (SERIO) will consolidate some of the current system functionality fragmented across import systems and develop system flexible enough to run on multiple devices when desired, i.e a device agnostic approach which will allow for the end to end processing of entries (entry review, investigation, compliance) in one integrated system. The system will have capabilities to enable work accomplished while offline to support field examination and sample collection activities later to be synched with the application and database layer. The SERIO system shall be developed to incorporate and support current import and imports related systems (see attached Fact Sheets for an overview of FDAs import systems). Note: any additional requirements and changes to the other imports systems will be provided at the time of award.

Requirements for the Import Investigation Time and Input Line Availability have been captured.

Specific Objectives for the period of performance are:

• Review the existing requirements and screen mockups for the Import Investigation Time and

Input Line Availability and make any necessary updates to the requirements and mockups.

• Enhance and expand the Entry Review system (aka SERIO) to build Import Investigation

Time and Input Line Availability.

• Enhance and expand SERIO to complete enhancements and production deployment for the

User Role Management, Mail and Baggage, Available Work Grab Bag, IB Personal Work Inbox, Record Time and Input IB Work Results. Any new enhancements will be identified during requirements sessions with ORA business.

• Develop requirements for the compliance functionalities currently residing in the OASIS system.

• Improve navigation relative to OASIS, such as the ability to navigate to other screens from the Work Personal Inbox and Available Work Grab Bag in SERIO.

• Implement Notices Generation and Printing.

• Enhance SERIO Entry Query to allow query for mail/baggage entries based on Postal

Tracking number or Reference Number as well as the capability to query commercial entries based on Container Number, Bill of Lading, Airway Bill Master, and Airway Bill House.

• Support integration with sample collection, sample analysis and field exam systems, including eFieldX, FACTS and LIMS.

1.3 Scope

The Contractor shall provide technical services to replace and enhance the functionality of the existing mission critical systems by building SERIO. The concept of SERIO is to expand the functionality currently available in Entry Review by adding additional OASIS capabilities such as Investigations Branch (IB), some of which have already been added, and the entire Compliance Branch (CB) portions of the FDA admissibility process. The scope of this task order is to develop requirements for Compliance functionalities and to expand Entry Review by enhancing Inboxes, Mail and Baggage module and IB functionality. This includes all applicable aspects of the FDA tailored Enterprise Performance Life Cycle (EPLC) and shall result in the development and of enhanced software.

It is the intent of the government that the Contractor utilizes an agile development methodology for this Task. Accordingly, the Statement of Work provides a set of objectives that describe the need for this period of performance. The Statement of Work further provides an initial set of functional requirements that are to be implemented. During the agile development effort, the government will work with the Contractor to manage the requirements backlog by prioritizing the requirements, approving the assignment of requirements to sprints and to releases, and by adding, modifying, and deleting requirements.

2.0 Description of Work

This SOW includes activities necessary to implement enhancements to meet the objectives stated in Section 1.2. The system development efforts must be coordinated and orchestrated to ensure continued system functionality and integration with the systems currently in use. To accomplish this, the Contractor shall coordinate with the owners of systems in Imports and other Investments that are impacted by the enhancements, as well as with other ORA task orders. Potentially impacted systems include Firm Management System (FMS), On-line Reporting, Analysis and Decision Support System (ORADSS), Product Code Wizard (PCW), eFieldX (mobile application), Field Accomplishments and Compliance Tracking System (FACTS), and Laboratory Information Management System (LIMS).

The contractor shall support and perform all lifecycle activities, documentation and software deliverables required/defined in this document, and shall follow standards and guidelines established in the contract ID/IQ. This includes the following activities:

1. Contractor shall be responsible for delivering application software as required to result in functioning implemented software. The work product shall include source code, executable code, installation scripts (automated and/or manual) and configurations.

2. Contractor shall coordinate with the imports business representatives and the Office of Information Management and Technology (OIMT) to plan a series of releases to meet the Objectives described above.

3. Contractor shall support and work with Imports business representatives, OIMT, other vendors, and various offices within ORA throughout the whole EPLC management process needed to ensure successful implementation, maintenance of current performance and functionality and to ensure that business needs are met.

4. The Contractor shall provide timely delivery of EPLC documentation and drafts for engagement, review and input from the (Integrated Project Team) IPT and stakeholders including OIM to ensure collaboration, inputs and commitment. There shall be at least one stage gate review conducted no later than 3 weeks before the end of the Period of Performance (POP). Adequate time is required to perform UAT prior to any release and to make any needed modifications identified, as well as time to perform successful, corrective UAT in time for the Production deployment of the systems changes.

5. Contractor shall provide ongoing technical and functional consultation and support activities as defined under this Task Order.

6. Contractor shall complete all implementation and deployment activities necessary to provide working software to the end users and to transition the software to the Operations and Maintenance contractor. Transition shall include documentation and instruction sufficient to enable the O&M team to diagnose and resolve any issues reported for the software. The Contractor shall be responsible for fixing any bugs found in the software during the first 90 days after the FDA begins use of the software. At the end of the Period of Performance or 90 days after the release, whichever occurs sooner, the Contractor shall transfer such responsibility to the O&M task.

7. Contractor shall provide technical input to support recommendations for a path forward regarding database and system changes/improvements for the legacy/mission critical systems used within the FDA to accommodate the modifications outlined in 2.1 Functional Objectives.

2.1 Functional Requirements (Initial Requirements Backlog)

The following are specific objectives under this task order. Screenshots of the current OASIS screens are included to illustrate the requirements.

2.1.1 Compliance Branch (CB) Functionality

Compliance Officers are responsible for making final admissibility decisions on product that has not been released during the Entry Review process or as a result of a non-violative field or label exam. This final decision will be either a type of release, or a refusal of admission, which gives the Importer of Record the option to either destroy or export the violative product. Compliance Officers initiate some post-refusal activities, which are the supervision of those destruction or exportation activities. They also oversee some intermediate processes such as the reconditioning of violative product, and the review of non-FDA laboratory analyses for product with the appearance of a violation of the Federal Food Drug &Cosmetic Act.

The Contractor shall gather requirements and develop screen mockups for the functionality below. Each action has a corresponding OASIS input screen associated with it. The availability of each action to the user is dependent on logic contained in the Activity Conditions table in OASIS which governs which activities must be present, or must not be present, on a line. This table will be provided as part of the requirements gathering process.

1. Migrate and enhance Next Step: Entry Options action. Entry options are actions that apply to all lines of an entry. For Compliance, these only apply to Mail/Baggage entries:

a. Return to IB for Disposition-Release

b. Return to IB for Disposition-Refused/Return To Sender

c. Return to IB for Disposition-Refused/Destroyed

d. Return to IB for Disposition-Partial Release/Partial Destroy

e. Return to IB for Disposition-Partial Return To Sender/Partial Destroy

Figure 1: Next Steps Screen

2. Migrate and enhance Next Step: Log Receipt & Response actions. These are a variety of activities which record the receipt of different types of information related to Compliance processes.

a. Log Line Availability

b. Miscellaneous Information Received

c. Mitigation Request Received

d. Reconditioning Request Received

e. Extension Request Received

f. Grant Extension Request

g. Deny Extension

h. Miscellaneous Information Received

i. Goods Available for Export/Destruction

j. Certificate of Export Received

k. Record Receipt Proof of Export Marking

l. Redelivery Information Received

m. Goods Redelivered for Exam/Collect

n. Log Line Availability

o. Miscellaneous Correspondence

Figure 2: Miscellaneous Information Received Screen

3. Migrate and enhance Next Steps: Work Requests actions. These are requests from

Compliance Branch to different groups to perform work.

a. Request IB Work

b. Request Technical Review

c. Request IB Work – Reconditioning

Figure 3: Request IB Work Screen

4. Migrate and enhance Next Steps: Record Results actions. These are options for the

Compliance Officer to record work results, either for work they performed, or work performed at their request that are not entered elsewhere.

a. Enter Label/Records Exam

b. Record Technical Review Results

c. Preliminary Lab Results Received

Figure 4: Enter Label/Records Exam Screen

5. Migrate and enhance Next Steps: Compliance Decisions actions. These are the most important Compliance activities including many final admissibility decisions, which determine whether the product represented by a line may enter commerce, or must be exported or destroyed as they are not in compliance with the Federal Food Drug and Cosmetic Act.

a. Grant Extension Request

b. Issue Detention

c. Issue Detention w/o Physical Exam

d. Issue Detention/May Be Destroyed (Mail/Baggage entries only)

e. Amend/Withdraw Detention

f. Extend Compliance Branch Follow Up Period

g. Issue Refusal Inform Before Export

h. Issue Refusal Inform After Export

i. Release w/Comment after Detention

j. Issue Release

k. Issue Release with Comment

l. Release after Detention

m. Issue Release for All Materials

n. Issue Refusal for All Materials Before Export

o. Issue Refusal for All Materials After Export

p. Issue Refusal for Remainder Inform Before Export

q. Issue Refusal for Remainder Inform After Export

r. No Further Action

s. Demand Exam/Collect Redelivery

t. Issue Refusal-M&B/Return to Sender

u. Rescind Refusal - Restore Previous Action

v. Issue Refusal-M&B/Return to Sender (Mail/Baggage entries only)

w. Issue Refusal-M&B/Destroy (Mail/Baggage entries only)

Figure 5: Issue Detention Without Exam Screen

6. Migrate and enhance Next Steps: Non-FDA Lab actions. These are the various activities related to the receipt, evaluation and acceptance or rejection of private lab analyses submitted by trade to overcome the appearance of a violation of the FD&C Act.

a. Non-FDA Lab Analysis Received

b. Request IB Work – Audit

c. Perform Audit

d. Accept Non-FDA Lab Analysis w/o Review

e. Accept non-FDA Lab Analysis/Review

f. Review Non-FDA Lab Analysis

g. Reject Non-FDA Lab Analysis w/o Review

h. Reject non-FDA Exam/Review/Resubmit

i. Reject non-FDA Lab/Review/No Resubmission allowed

j. Private Lab Confirmation of Violation

k. Accept Non-FDA Analysis /After Exam Audit

l. Reject Non-FDA Analysis /After Exam Audit

m. Enter Non-FDA Lab Analysis Results

n. Accept non-FDA Lab Analysis/Review

o. Reject non-FDA Exam/Review/Resubmit

p. Reject Lab Analysis w/Resubmission allowed -Exam Audit

Figure 6: Log Receipt of Non-FDA Lab Analysis Screen

7. Migrate and enhance Next Steps: Reconditioning actions. These are various activities related to the reconditioning of product which has been found to be violative, in an attempt to bring it into compliance with the FD&C Act.

a. Reconditioning Request Received

b. Reconditioning Request Incomplete Allow Resubmission

c. Reconditioning Request Denied/No Resubmission allowed

d. Reconditioning Request Denied /Resubmission allowed

e. Approve Reconditioning w/o Supervision

f. Approve Reconditioning w/ Supervision

g. Conditionally Approve Reconditioning

h. Conditionally Approve with Supervision

i. Allow Further Reconditioning

j. Reconditioning Unsuccessful - No Resubmission allowed

k. Reconditioning Unsuccessful-Allow Resubmission

l. Input Reconditioning Results

m. Approve Further Reconditioning W/Supervision

n. Approve Further Reconditioning W/Conditions

o. Approve Further Reconditioning W/Conditions W/Supervision

p. Goods Available for Reconditioning Received

q. Reconditioning Completion Notice Received

r. Waive Reconditioning Supervision

s. Enter Reconditioning Lab Analysis Result

Figure 7: Approve Reconditioning with Supervision Screen

8. Migrate and enhance Next Steps: Post Refusal actions. A product is refused when it is determined to have the appearance of being in violation of the FD&C Act. After a line has been refused, if FDA has requested evidence of destruction or exploration, or if CBP has been requested to issue monetary penalties, one or more of the following activities may be appropriate.

a. Mitigation Request Received

b. Evaluate Mitigation Request

c. Record Receipt of Proof of Export Marking

d. USCS Fine Information Received

e. Goods Available for Export/Destruction

f. Certificate of Export Received

g. Request IB Work – Refusal

h. Input Certificate of Export Data

i. Request USCS Penalty Action

j. Export Supervision Waived - Inform After

Figure 8: Mitigation Request Received Screen

9. Migrate and enhance Next Steps: OGA Activities actions. At times, it is necessary to refer a product to an Other Government Agency (OGA) such as USDA or APHIS due to violations of their regulations that have been observed. This also includes referrals to Customs and Border Protection (CBP) for seizure or destruction in certain circumstances.

a. Refer to OGA

b. Request Status Update from OGA

c. Record OGA Response

d. Record Lack of OGA Response

e. Close OGA Referral

f. Refer to CBP for Seizure/Destruction

g. Response from CBP

h. Close OGA Referral/May Proceed

i. Close OGA Referral/No Further

Figure 9: Refer to CBP for Seizure/Destruction Screen (OGA Notice Selection)

10. Migrate and enhance CB grab bags: Available Work, Personal and Personal/Refusal, including filtering capabilities (allow for multiple preferences to be applied to grab bags to be saved for each user)

11. Migrate and enhance Compliance Same Action As (SAA) linking capability. Linking multiple similar lines in an entry allows the Compliance Officer to avoid repetitious actions by copying the actions taken on the ‘lead’ line to all the ‘member’ lines of the Same Action As group.

2.1.2 Investigation Branch (IB) Functionality

Investigators are responsible for conducting field examinations and sample collections, shipping samples to a lab for analysis and making final admissibility decisions on product that has not been released during the Entry Review process. This final decision will be a type of release.

Investigators also determine if a product needs a further review by a compliance officer based on the outcome of examination.

The contractor shall develop enhancements that are identified by ORA business during requirements sessions for the following modules: the User Role Management, Mail and

Baggage, Available Work Grab Bag, IB Personal Work Inbox, Record Time and Input IB Work Results. Below are the associated OASIS screens.

1. Personal Work Inbox.

Figure 10: Personal Work Inbox Screen

2. IB Available Work Grab Bag

Figure 11: Available Work Grab Bag Screen

3. Input Work Results and record time.

Figure 12: Input Work Results Screens

4. Migrate and enhance Import Investigation Time.

a. The system shall allow users to enter the amount of time they have spent on an action along with the following information: Accomplishment Date, Number of Hours, What Activity, Number of Line, Package Count, Product Code Information, Problem Area Flag, Program Assignment Code, Country of Origin. The applicable actions for investigation are: Entry Review, General Import Investigation and Mail/Baggage Review.

Figure 13: Inport Investigation Time Screen

5. Migrate and enhance Input Line Availability.

a. The system shall allow users to view the following line availability information provided by trade through ITACS for a selected line: The Date that the product is available for FDA examination when need be, the Facility Name, Contact People information, Warehouse/Pier Log Number, Street Address. In addition, the system shall allow users to input the following line availability information: Hours of Operation of the Facility, Location of Goods and any additional information.

Figure 14: Input Line Availability Screen

6. Enhance Mail and Baggage by adding the following functionalities plus any additional functionality that has been captured or will be added during requirements sessions with ORA business.

a. Develop new work types, workflows and associated input for recording results of Rapid

Screening Tool use (IMS, CD3, XRF, Raman Spectrometer, NIR, and others to be identified during requirements gathering). Each tool requires the capture of different data elements and will need its own screen.

b. CBP Referral- Scheduled Drugs & Opioids- create a new type of mail Baggage entry (in addition to the existing entry types of 67-mail & 66- baggage, which will create an entry with less mandatory information and the only option will be referring to CBP/DEA. This will allow the agency to report this activity which is not currently captured in the system.

7. Implement user friendly navigation in SERIO. The following screens require easy navigational abilities from Personal Inbox and AWGB in SERIO:

a. Entry Query: Ability to navigate directly to Entry Query from Personal Inbox/AWGB. In OASIS the user double clicks on the entry number from Personal Inbox or AWGB and navigates to Entry Query. While ER has the Query arrow button that allows quick navigation to Entry Query. Business is fine with the way it works in ER as long as SERIO user is able to navigate directly to Entry Query from Personal Inbox/AWGB.

b. Entry Line Summary: Ability to navigate directly to Entry Line Summary from Personal Inbox/AWGB. In OASIS the user double clicks on the work type from Personal Inbox or AWGB and navigates to Entry Line Summary. Business would like to mimic a similar easy navigation in SERIO.

c. Line Details: Ability to navigate directly to Line Details from Personal Inbox/AWGB. In OASIS the user double clicks on Est. Completion date from Personal Inbox or AWGB and navigates to Screening Hits screen which is currently part of Line Details in ER (Screening Results section). Per Business, we do not have to mimic the exact OASIS flow in SERIO. However, ensure the user has a quick way to navigate easily to Line Details from Personal Inbox/AWGB so that user can get to the Screening Hits section from there.

d. Description: Ability to navigate directly to Description from Personal Inbox/AWGB. In

OASIS the user double clicks on Description from Personal Inbox or AWGB and gets a pop-up with the detailed Description. Business would like to mimic a similar easy navigation in SERIO.

8. Enhance SERIO Entry Query to add functionality of query and display mail/baggage data elements for mail/baggage entries based on Entry Number, Postal Tracking number or Reference Number as well as the capability to query commercial entries based on Container Number, Bill of Lading, Airway Bill Master, and Airway Bill House.

9. Migrate and enhance OASIS functionality to print and reprint Notices of FDA Action both asynchronously and in batches. Complete development and production implementation.

10. Support integration with sample collection, sample analysis and field exam systems, including eFieldX, FACTS and LIMS.

11. Support production rollout of new screens stated above to five ORA import divisions.

Note that the need for additional requirements may be identified during the requirements gathering process.

2.1.3 OASIS Database Objects Consolidation, Cleanup and Improvement The Contractor shall conduct analysis on the existing OASIS database objects and provide recommendations for consolidation, cleanup and improvement. A list of tables and OASIS screens and database objects categorization will be provided on award. The OASIS database contains approximately 800 tables.

3.0 Task Order Management

The Contractor shall conduct all activities necessary to manage the Task Order following project management best practices. These activities shall include managing cost, schedule, quality, risk, and communications with stakeholders. The Contractor shall identify a Project Manager with responsibility for the team conducting the work and a Senior Information Engineer who will provide technical leadership. The Contractor may choose to fill these labor category positions with one person or two people. However, if the contractor elects to fill the labor category positions with one person, the individual must satisfy the requirements for both labor category descriptions.

The Contractor shall recommend a management and organizational approach to deploy resources and meet the requirements outlined in the active task orders. To minimize overhead, the Contractor may propose to combine meetings and reporting requirements at a level that provides the necessary level of insight and control. The Contractor shall provide a brief proposed management approach proposal that supplements the contract Management Plan by outlining the proposed grouping of objectives, the team structure that will be used to perform the work, and identifying the management staff and lines of responsibility. The COR will provide feedback on the proposed approach and approve the final approach.

Within 2 weeks of the Task Order start date, the Contractor shall schedule a Task Order Kick Off to present the team organization, introduce the team, and address key tasks, schedule, assumptions, constraints, and risks. The Contractor shall schedule a status meeting at least once/week and provide input to the status reporting described in the ID/IQ and the Program Management and Integration Task Order. The Contractor shall schedule additional business and technical meetings as required to meet the objectives of the Task Order.

This SOW consists of several initiatives requiring changes to multiple ORA IT systems. This work must be managed in a coordinated fashion, but will involve several teams of ORA, OIMT, and contractor staff. The effort must also be managed in conjunction with other task orders to ensure ORA’s needs are met efficiently without unexpected impacts to Production systems.

4.0 Deliverables

The contractor shall provide the following deliverables.

Deliverable/Artifact Frequency Due Date Task Order Kick-off meeting presentation

Once. By 2 weeks after the task order award.

Project Process Agreement

(PPA)

Once for each release. Two weeks after release content is approved.

EPLC documentation as detailed in the PPA

Drafts as needed. Final deliverables at least 5 business days prior to the Stage Gate Review for each release.

As required by EPLC.

Successful Stage Gate Review

(s) (Go or Go with Conditions) as detailed in the

PPA

At Least Once for each release. No later than 3 weeks before the end of the POP and at least three business days prior to any major release.

Project Schedule Bi-weekly. Initial Draft 2 weeks after Task Order start with updates weekly.

Project Risks and Issues list As designated by the COR, not more than weekly.

Initial Draft 2 weeks after Task Order start with updates weekly with Status Meeting materials.

Status Meeting:

• Agenda

• Minutes from prior meeting

As designated by the COR, not more than weekly.

Agenda at least one business day prior to the meeting.

Meeting minutes no later than two business days following the meeting.

Status and Financial Reports Monthly. Included as a section in the IDIQ reports and financial reporting.

Note that EVM reporting is required for this task.

Complete and tested software source and executable code (Production ready)

Once for each Production Release (may be delivered in incremental releases to deliver functionality as completed).

Final delivery no later than 3 weeks prior to task order end.

Implementation Deliverables, including detailed implementation plan, Run Book, training materials (as requested by ORA), and user guide and system improvement

One Draft and one Final version of each for each Release.

Draft due at time of installation in Pre-Production.

Final due at least three days prior to installation in Production.

recommendations. May be new or updated documents depending on the need.

Requirements Walkthroughs, software demonstrations, sprint reviews and demonstrations, UAT support meetings

• Agenda

• Minutes

Per project schedule Agenda at least one business day prior to the meeting.

Meeting minutes no later than two business days following the meeting.

Transition Materials (all documentation necessary for transition the software from the other contractor)

As directed by the COR. Not more than once/release.

At least 3 weeks prior to task order end.

Technical Information/Database Path Forward Analysis Document

As directed by the COR. As directed by the COR. Draft at least 3 months prior to Task Order completion.

• Deliverables shall be presented to the FDA COR on the dates specified in the Table.

• Documents shall be clearly written in plain English.

• Documents shall be complete and accurate.

• Documents shall be brief to meet the desired need.

• Project Schedule changes shall be first submitted by the Contractor to the COR for review and approval before incorporation into the schedule.

5.0 General Requirements

The Contractor shall comply with the provisions in the IDIQ (indefinite delivery/indefinite quantity), including all EPLC, Security, Privacy, 508 Compliance, and Architecture requirements. The contractor shall support and perform all lifecycle activities, documentation and deliverables required. Unless specifically stated, all work requirements are inclusive of all activities to support implementation necessary to deliver support and functionality to end users This includes the following activities:

1. The Contractor shall coordinate with the business representatives and the Office of

Information Management and Technology (OIMT) to plan the activities described above and to track the execution of key tasks. Such coordination may include review and/or demonstrations of software components to promote understanding of proposed changes.

2. The Contractor shall support and work with business representatives, OIMT, other vendors, and various offices within ORA throughout the whole EPLC management process as needed to ensure successful implementation, maintenance of current performance and functionality, and to ensure that business needs are met.

3. The Contractor shall coordinate with teams developing O&M and other DME releases to plan for and execute coordinated software releases where applicable. Releases may include both content developed within a DME task and that developed in the O&M task, and software developed by a DME team may require simultaneous changes developed by the O&M team.

4. Although ORA’s objective is that software shall comply with the ORA Reference Architecture, rigorous compliance for the software implemented in this task order may be prohibitively expensive. The Contractor shall develop code in an efficient manner without unnecessary introduction of changes that would deviate from the Reference Architecture.

Where possible, the contractor shall use designated common components (e.g., auditing, error handling, data access) as appropriate and recommended integration mechanisms (e.g., API).

5. This task includes, but is not limited to, modifications to any ORA systems in an ORA managed investment and coordination with the owners of systems in other Investments that are impacted by the enhancements, as well as with other ORA task orders.

6. The Contractor shall ensure that all staff (Prime and Subcontractor) comply with the HHS criteria for the assigned position sensitivity designations prior to performing any work under this contract.

[X] Level 4: Public Trust ‐ Non-Sensitive (no National Security)/High Risk. Contractor employees assigned to a Level 4 position with no previous investigation and approval shall undergo a National Agency Check and Inquiry Investigation plus a Credit Check (NACIC), a Minimum Background Investigation (MBI), or a Limited Background Investigation (LBI).

6.0 Acceptance Criteria

The COR shall determine if the deliverables for this task order are acceptable. For functionality, the following performance characteristics will be referred to in determining acceptance. This list is not all-inclusive.

1. Developed functionality should be robust to support 24x7 operations.

2. Any new screens are built to provide responses in less than 0.5 seconds within the greater

Washington DC metropolitan area (response time is based on the system response with any network delays subtracted).

3. Any modifications shall provide performance equal to or greater than the current components. The government expects an appropriate level of performance testing be conducted for all releases.

4. Maximize the use of system to system transactions requiring no human interaction.

5. Maximize the use of re-usable components ·and a repository of re-usable components.

6. Maximize flexibility for connecting to third party (commercial products, Center databases, other Agencies) data stores via native configuration.

7.0 Contract Type

This Task Order is Labor Hours. This Task will only include deliverables that are directly related to the activities indicated within.

8.0 Period of Performance

The period of performance for this task order is twelve months from the date it is awarded.

9.0 Security and Confidential Treatment of Sensitive Information

9.1 Security Requirements

A. Baseline Security Requirements

1) Applicability. The requirements herein apply whether the entire contract or order (hereafter “contract”), or portion thereof, includes either or both of the following:

a. Access (Physical or Logical) to Government Information: A Contractor (and/or any subcontractor) employee will have or will be given the ability to have, routine physical (entry) or logical (electronic) access to government information.

b. Operate a Federal System Containing Information: A Contractor (and/or any subcontractor) will operate a federal system and information technology containing data that supports the HHS mission. In addition to the Federal Acquisition Regulation (FAR) Subpart 2.1 definition of “information technology” (IT), the term as used in this section includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services), and related resources.

2) Safeguarding Information and Information Systems. In accordance with the Federal Information Processing Standards Publication (FIPS)199, Standards for Security Categorization of Federal Information and Information Systems, the Contractor (and/or any subcontractor) shall:

a. Protect government information and information systems in order to ensure:

• Confidentiality, which means preserving authorized restrictions on access and disclosure, based on the security terms found in this contract, including means for protecting personal privacy and proprietary information;

• Integrity, which means guarding against improper information modification or destruction, and ensuring information non-repudiation and authenticity; and

• Availability, which means ensuring timely and reliable access to and use of information.

b. Provide security for any Contractor systems, and information contained therein, connected to an FDA network or operated by the Contractor on behalf of FDA regardless of location. In addition, if new or unanticipated threats or hazards are discovered by either the agency or contractor, or if existing safeguards have ceased to function, the discoverer shall immediately, within one (1) hour or less, bring the situation to the attention of the other party. This includes notifying the FDA Systems Management Center (SMC) within one (1) hour of discovery/detection in the event of an information security incident.

c. Adopt and implement the policies, procedures, controls, and standards required by the HHS/FDA Information Security Program to ensure the confidentiality, integrity, and availability of government information and government information systems for which the Contractor is responsible under this contract or to which the Contractor may otherwise have access under this contract. Obtain the FDA Information Security Program security requirements, outlined in the FDA Information Security and Privacy Policy (IS2P), by contacting the CO/COR or emailing your ISSO.

d. Comply with the Privacy Act requirements and tailor FAR clauses as needed.

3) Information Security Categorization. In accordance with FIPS 199 and National Institute of Standards and Technology (NIST) Special Publication (SP) 800-60, Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories, Appendix C, and based on information provided by the ISSO or other security representative, the risk level for each Security Objective and the Overall Risk Level, which is the highest watermark of the three factors (Confidentiality, Integrity, and Availability) of the information or information system are the following:

Confidentiality: [ ] Low [ ] Moderate [X] High Integrity: [ ] Low [ ] Moderate [X] High Availability: [ ] Low [ ] Moderate [X] High Overall Risk Level: [ ] Low [ ] Moderate [X] High

Note that the ORA systems are managed within several security “boundaries”, and thus different Risk Levels may be assigned to different systems. The assessment above is for the highest risk systems.

Based on information provided by the Privacy Office, system/data owner, or other privacy representative, it has been determined that this solicitation/contract involves:

[ ] No PII [X] Yes PII

Note that some, but not all, ORA systems contain PII.

Personally Identifiable Information (PII). Per the OMB Circular A-130, “PII is information that can be used to distinguish or trace an individual's identity, either alone or when combined with other information that is linked or linkable to a specific individual.” Examples of PII include, but are not limited to the following:

Social Security number, date and place of birth, mother’s maiden name, biometric records, etc.

PII Confidentiality Impact Level has been determined to be: [ ] Low [ ] Moderate [ ]

High

4) Controlled Unclassified Information (CUI). CUI is defined as “information that laws, regulations, or Government-wide policies require to have safeguarding or dissemination controls, excluding classified information.” The Contractor (and/or any subcontractor) must comply with Executive Order 13556, Controlled Unclassified Information, (implemented at 3 CFR, part 2002) when handling CUI. 32 C.F.R. 2002.4(aa). As implemented the term “handling” refers to “…any use of CUI, including but not limited to marking, safeguarding, transporting, disseminating, re- using, and disposing of the information.” 81 Fed. Reg. 63323. All sensitive information that has been identified as CUI by a regulation or statute, handled by this solicitation/contract, shall be:

a. marked appropriately;

b. disclosed to authorized personnel on a Need-To-Know basis;

c. protected in accordance with NIST SP 800-53, Security and Privacy

Controls for Federal Information Systems and Organizations applicable baseline if handled by a Contractor system operated on behalf of the agency, or NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations if handled by internal Contractor system; and

d. returned to FDA control, destroyed when no longer needed, or held until otherwise directed. Destruction of information and/or data shall be accomplished in accordance with NIST SP 800-88, Guidelines for Media Sanitization and the FDA IS2P Appendix T: Sanitization of Computer-Related Storage Media.

5) Protection of Sensitive Information. For security purposes, information is or may be sensitive because it requires security to protect its confidentiality, integrity, and/or availability. The Contractor (and/or any subcontractor) shall protect all government information that is or may be sensitive in accordance with OMB Memorandum M-06-16, Protection of Sensitive Agency Information by securing it with a FIPS 140-2 validated solution.

Confidentiality and Nondisclosure of Information. Any information provided to the contractor (and/or any subcontractor) by FDA or collected by the contractor on behalf of FDA shall be used only for the purpose of carrying out the provisions of this contract and shall not be disclosed or made known in any manner to any persons except as may be necessary in the performance of the contract. The Contractor assumes responsibility for protection of the confidentiality of Government records and shall ensure that all work performed by its employees and subcontractors shall be under the supervision of the Contractor. Each Contractor employee or any of its subcontractors to whom any FDA records may be made available or disclosed shall be notified in writing by the Contractor that information disclosed to such employee or subcontractor can be used only for that purpose and to the extent authorized herein.

The confidentiality, integrity, and availability of such information shall be protected in accordance with HHS and FDA policies. Unauthorized disclosure of information will be subject to the HHS/FDA sanction policies and/or governed by the following laws and regulations:

1. 18 U.S.C. 641 (Criminal Code: Public Money, Property or Records);

2. 18 U.S.C. 1905 (Criminal Code: Disclosure of Confidential Information); and

3. 44 U.S.C. Chapter 35, Subchapter I (Paperwork Reduction Act).

6) Internet Protocol Version 6 (IPv6). All procurements using Internet Protocol shall comply with OMB Memorandum M-05-22, Transition Planning for Internet Protocol Version 6 (IPv6).

7) Government Websites. All new and existing public-facing government websites must be securely configured with Hypertext Transfer Protocol Secure (HTTPS) using the most recent version of Transport Layer Security (TLS). In addition, HTTPS shall enable HTTP Strict Transport Security (HSTS) to instruct compliant browsers to assume HTTPS at all times to reduce the number of insecure redirects and protect against attacks that attempt to downgrade connections to plain HTTP. For internal-facing websites, the HTTPS is not required, but it is highly recommended.

8) Contract Documentation. The Contractor shall use FDA-provided templates, policies, forms and other agency documents to comply with contract deliverables as appropriate. See Table xx for baseline security/privacy deliverables

9) Standard for Encryption. The Contractor (and/or any subcontractor) shall:

a. Comply with the HHS Standard for Encryption of Computing Devices and Information to prevent unauthorized access to government information.

b. Encrypt all sensitive federal data and information (i.e., PII, protected health information [PHI], proprietary information, etc.) in transit (i.e., email, network connections, etc.) and at rest (i.e., servers, storage devices, mobile devices, backup media, etc.) with FIPS 140-2 validated encryption solution.

c. All devices (i.e.: desktops, laptops, mobile devices, etc.) that store, transmit, or process non-public FDA information should utilize FDA-provided or FDA information security authorized devices that meet HHS and FDA-specific encryption standard requirements. Maintain a complete and current inventory of all laptop computers, desktop computers, and other mobile devices and portable media that store or process sensitive government information (including PII).

d. Verify that the encryption solutions in use are compliant with FIPS 140-2. The Contractor shall provide a written copy of the validation documentation to the COR.

e. Use the Key Management system on the HHS Personal Identification

Verification (PIV) card or establish and use a key recovery mechanism to ensure the ability for authorized personnel to encrypt/decrypt information and recover encryption keys. Encryption keys (PIV card) shall be provided to the COR upon request and at the conclusion of the contract. Upon completion of contract, contractor ensures that COR is able to access and read any encrypted data.

10) Contractor Non-Disclosure Agreement (NDA). Each Contractor (and/or any subcontractor) employee having access to non-public government information under this contract shall complete the FDA non-disclosure agreement (3398 Form), as applicable. A copy of each signed and witnessed NDA shall be submitted to the CO and/or COR prior to performing any work under this acquisition.

11) Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA) –

The Contractor shall assist the procuring activity representative, program office and the FDA SOP or designee with conducting a PTA for the information system and/or information handled under this contract to determine whether or not a full PIA needs to be completed.

a. If the results of the PTA show that a full PIA is needed, the Contractor shall assist procuring activity representative, program office and the FDA SOP or designee with completing a PIA for the system or information after completion of the PTA and in accordance with HHS and FDA policy and OMB M-03-22, Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002. The PTA/PIA must be completed and approved prior to active use and/or collection or processing of PII and is a prerequisite to agency issuance of an authorization to operate (ATO).

b. The Contractor shall assist the procuring activity representative, program office and the FDA SOP or designee in reviewing and updating the PIA at least every three years throughout the Enterprise Performance Life Cycle (EPLC) /information lifecycle, or when determined by the agency that a review is required based on a major change to the system, or when new types of PII are collected that introduces new or increased privacy risks, whichever comes first.

B. Training

1) Mandatory Training for All Contractor Staff. All Contractor (and/or any subcontractor) employees assigned to work on this contract shall complete the applicable FDA Contractor Information Security Awareness, Privacy, and Records Management training (provided upon contract award) before performing any work under this contract. Thereafter, the employees shall complete FDA Information Security Awareness, Privacy, and Records Management training at least annually, during the life of this contract. All provided training shall be compliant with HHS and FDA training policies.

2) Role-based Training. All Contractor (and/or any subcontractor) employees with significant security responsibilities (as determined by the program manager) must complete role-based training annually commensurate with their role and responsibilities in accordance with HHS and FDA policy and FDA Role-Based Training (RBT) of Personnel with Significant Security Responsibilities Standard Operating Procedures (SOP).

3) Training Records. The Contractor (and/or any subcontractor) shall maintain training records for all its employees working under this contract in accordance with HHS and FDA policy. A copy of the training records shall be provided to the CO and/or COR within 30 days after contract award and annually thereafter or upon request.

C. Rules of Behavior

1) The Contractor (and/or any subcontractor) shall ensure that all employees performing on the contract comply with the HHS Information Technology General Rules of Behavior.

2) All Contractor employees performing on the contract must read and adhere to the Rules of Behavior (ROB) before accessing HHS and FDA data or other information, systems, and/or networks that store/process government information, initially at the beginning of the contract and at least annually thereafter, which may be done as part of annual FDA Information Security Awareness Training. If the training is provided by the contractor, the signed ROB must be provided as a separate deliverable to the CO and/or COR per defined timelines.

D. Incident Response The Contractor (and/or any subcontractor) shall respond to all alerts/Indicators of Compromise (IOCs) provided by HHS Computer Security Incident Response Center (CSIRC)/FDA SMC /Incident Response Team (IRT) teams within 24 hours, whether the response is positive or negative.

FISMA defines an incident as “an occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” The HHS Policy for IT

Security and Privacy Incident Reporting and Response further defines incidents as events involving cybersecurity and privacy threats, such as viruses, malicious user activity, loss of, unauthorized disclosure or destruction of data, and so on.

A privacy breach is a type of incident and is defined by FISMA as the loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where (1) a person other than an authorized user accesses or potentially…