Atch_5_Assignments_SOW.pdf

RFP Attachment 5

Task 4 - Assignment Module Enhancements

1.0 Introduction

The Food and Drug Administration (FDA) is responsible for protecting the public health by assuring the safety, efficacy, and security of numerous products including: human and veterinary drugs, biological products, medical devices, our nation’s food supply, cosmetics, and products that emit radiation. The Office of Regulatory Affairs (ORA) contributes to this effort by assigning and conducting work (e.g.

inspections, investigations, sample collection, etc.) (referred to throughout this document as operations) on the above-mentioned products and the associated firm(s). In fiscal year 2017 alone, roughly 85,000 assignments were created that resulted in 137,000 operations with an average of 234 assignments created by an average of 70 users per day. ORA seeks to enhance the current assignment creation process through an autonomous service.

Currently, work assignments are generated, stored, and tracked in various internal FDA systems such as the Field Accomplishments and Compliance Tracking System (FACTS), eNSpect, and Panorama. These systems as described below will use the proposed autonomous service in place of their current method for creating, tracking, and completing assignments.

1. The Field Accomplishments and Compliance Tracking System (FACTS) - Provides a comprehensive system for use by ORA HQS, Field Staff, and Center personnel. FACTS records and tracks assignments for the following operation types: a) Consumer Complaints, b) Domestic Inspections, c) Domestic Investigations, d) Field Examinations/Tests, e) Foreign Inspections, f) Foreign Investigations, g) Import & Domestic Sample Analysis, and h) Import & Domestic Sample Collection Work Assignments and Accomplishment Hours.

2. eNSpect - A system that manages the ORA inspectional operations process via: a) an online component used by Supervisors to assign inspections and review the results and documentation, and b) an offline component used by Investigators on their laptops to perform their inspections at remote firms.

3. Panorama - A system developed by the Center for Drug Evaluation and Research (CDER), that captures Inspection Assignment Requests (IARs) that are sent to the Office of Regulatory Affairs (ORA) so operational inspections can be performed and completed. Panorama uses the Establishment Evaluation System (EES) interface to push inspection assignment requests and associated information to FACTS. Panorama interfaces with FACTS through a set of intermediate staging tables which allows creating and tracking assignments for inspection operations without manually entering the information into or accessing FACTS.

Refer to the Appendix for systems screenshots and data elements that can be utilized to read and write assignment information to the service.

2.0 Objective

The objective of the Assignment Module Enhancement initiative is to establish an autonomous service and user interface that will: 1) allow other FDA systems to create assignments (e.g. create, assign, edit, process, and report capabilities) that can support multiple operations, 2) allow other systems to “read from” and “write to” the service, 3) allow for the eventual decommissioning of the FACTS assignment module, while supporting other existing FACTS operations, 3) allow for the consolidation and automation of operational assignments, and 4) allow for the service to be accessed by reporting systems. ORA presupposes this objective will be best achieved by leveraging the existing eNSpect Online assignment functionality and existing services (see Appendix - eNSpect online) while enhancing the eNSpect user interface and database to support the requirements defined in section 4 below rather than develop a new system or utilize a commercial off the shelf solution. However, it is expected that the contractor will evaluate the options and determine the best overall solution to achieve the longer-term objective of an autonomous service solution for assignments.

3.0 Scope

The Contractor shall provide technical services to improve the functionality of assignment creation and completion across systems. This includes all applicable aspects of the FDA tailored Enterprise Performance Life Cycle (EPLC) and shall result in the development and deployment of software meeting approved requirements.

It is the intent of the government that the Contractor utilize an agile development methodology for this task order. Accordingly, this Statement of Work (SOW) provides a set of objectives that describe the high-level need for this period of performance. This SOW further provides an initial set of functional requirements that are to be considered the basis for an initial requirements backlog and to estimate the level of effort. 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 releases, and by adding, modifying, and deleting requirements.

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

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 IDIQ (Indefinite Delivery/Indefinite Quantity). This includes the following activities:

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

2. Contractor shall work with FDA Staff to develop and support an IPT to define, refine and validate requirements for the development and creation of operational assignments to be carried out by the Field/Center staff.

3. Contractor shall coordinate with the business representatives and the Office of Information Management and Technology (OIMT) to plan a series of releases to meet the Objectives described above. The content of each release will be approved by ORA and OIMT project managers. The FDA project managers, through the COR, will approve changes to release content resulting from additional analysis and development during the agile development process.

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

5. The Contractor shall conduct readiness or checkpoint reviews (sprint reviews) to provide timely coverage of major progress including requirements definition, design, development, prototypes, demonstrations, and testing. There shall be at least one stage gate review for each major release, conducted no later than 3 weeks before the end of the Period of Performance (PoP). Adequate time is required to be scheduled to perform UAT, make any needed modifications identified, and perform successful corrective UAT prior to any release.

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 (O&M) team. 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 30 days after the release, whichever occurs sooner, the Contractor shall transfer such responsibility to the O&M task.

7. Contractor shall ensure adequate user manuals and frequently asked questions are developed or updated and readily accessible to users to support new releases of functionality.

4.0 Functional Requirements

The below are the key functional system requirements and are intended to provide guidance on an enhanced assignment system:

1. Autonomous service to support operational assignment creation across systems - The Contractor shall develop an autonomous service to allow operational assignments to be created, assigned, edited, processed, and reported by other FDA systems in real time. The service will allow the system receiving the data to apply system specific rules to ingested data to ensure that business rules are maintained after the transfer process. For example, if an assignment is generated in system “x” and sent to system “y”, the assignment is subject to the operational rules (validation, permissions, routing procedures, and closing procedures) of system “y”. Assignments shall be stored in a database designated by the ORA technical steering group. Creation of a new database is strongly discouraged. The assignments creation capability shall continue to be accessible from the eNSpect Online interface. The interface to support the creation of assignments will be housed in FDA’s data center and does not require a mobile component. Strict attention to software and database changes must be adhered to in order to maintain the integrity of FACTS, eNSpect, and other impacted systems’ data and operations.

Background: Currently assignments are created using one of two methods: 1) manual entry which can be cumbersome and can result in tracking issues, or 2) via a series of staging tables (Panorama) which can be inflexible and cause difficulty when the assignment creation needs to be modified or enhanced. Implementation of this requirement will provide more flexibility, reduce the assignment entry burden, and allow for greater tracking capabilities.

2. Assignments Management User Interface Design and Development – The Contractor shall design a user interface to support the capabilities described in the “autonomous service to support operational assignment creation across systems” requirement above. The Contractor shall provide additional functions needed to manage assignments such as maintaining, tracking, and viewing the status of assignments. The Contractor shall provide the capability for Organizational units to forward assignments for different operation types. The provided autonomous service shall be developed as an enhancement to eNSpect, or if developed separately, shall integrate seamlessly with eNSpect Online. The service shall replace existing user interfaces for assignments modules currently provided by FACTS.

Background: Currently assignments are stored in disparate locations. Implementation of this requirement will allow for a single storage repository to allow Divisions to track and report on all requested work and provides a single definitive source for all systems responsible for creating and reading assignment requests and statuses.

3. Generate Multiple Operations from a Single Assignment - The Contractor shall allow the assignment module to create multiple operations (i.e. a simultaneous investigation and inspection) from a single assignment.

Background: Currently the eNSpect Online application and the data model only supports the creation of one operation for each assignment, i.e. a single assignment can only result in either a single inspection or investigation. For current eNSpect operations the 1-to-1 assignment-to-operations relationship is acceptable; however, for other operations such as sample collections one assignment shall be able to generate multiple collection operations. Implementation of this requirement will increase efficiency by reducing the data entry burden and will increase data accuracy.

4. Support Assignment Reporting - The Contractor shall work with Regulatory Business Information Services (RBIS) team to ensure ORA reporting systems such as the Online Search and Retrieval (OSAR) and the Online Reporting Analysis and Decision Support System (ORADSS) can read and transfer information from the autonomous service into an existing data warehouse and/or allow reporting systems to access assignment data stored in the data warehouse.

Background: Currently, the data warehouse is retrieving minimal assignment information from FACTS and eNSpect. The expansion of assignment information (number, types, and statuses of assignments) are important for workload management, and access to this information using the primary reporting tools of ORA (OSAR and ORADSS) is necessary. Implementation of this requirement will allow for easier information retrieval.

5.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 Task Order Lead (Key Personnel) with responsibility for the team conducting the work. The Contractor may identify a separate Technical Lead who will provide technical leadership. However, the Task Order Lead may serve in both roles.

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

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

Deliverable/Artifact Frequency Due Date 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 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 recommendations. May be new or updated documents depending on the need.

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.

Requirements Walkthroughs, software demonstrations, sprint

Per project schedule Agenda at least one business day prior to

Deliverable/Artifact Frequency Due Date reviews and demonstrations, UAT support meetings

• Agenda

• Minutes the meeting.

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

Transition Materials (all documentation necessary to transition the software to the O&M team)

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

At least 3 weeks prior to task order end.

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

7.0 General Requirements

The Contractor shall comply with the provisions in the IDIQ, 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 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).

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

9.0 Contract Type

This task order is labor hour. This task will only include deliverables that are directly related to the activities indicated within.

10.0 Period of Performance

(Estimated)

September 2018 – September 2019

11.0 Acronyms

Acronym Full Name CDER Center for Drug Evaluation and Research EES Establishment Evaluation System EPLC Enterprise Performance Life Cycle FEI FDA Establishment Identifier eSAF Electronic State Access to FACTS FACTS Field Accomplishments and Compliance Tracking System OIMT Office of Information Management and Technology ORADSS Online Reporting Analysis Decision Support System OSAR Online Search and Retrieval

12.0 Glossary

Word Definition

Assignment

A record used to indicate the type of work that is requested of staff, details of the work and firms associated with it. All assignments have a common set of data elements.

Operation

Work performed by staff because of an assignment. Each operation type can have different data elements that support the work. Various operations and the processes they involve can be found in the FDA Investigations Operations Manual (https://www.fda.gov/ICECI/Inspections/IOM/).

Investigator

Staff member that performs the operation initiated by an assignment. Most often referred to those performing inspections and investigations.

Appendix – System Descriptions, Screenshots, and Data Element Definitions

FACTS

Overview: FACTS is the primary application from where most operations are assigned, and the results of the work are tracked. Relevant assignment data (see Figure 1 and Figure 2 below for assignment data elements) are collected, entered into FACTS, and assigned to an organization and an investigator in that organization.

Technology: FACTS is an Oracle Forms-based Web application.

Interfaces: There are several systems within the FDA that interface with FACTS to retrieve data, push data, or a combination of both. The FACTS database also stores assignments that are generated from systems outside of ORA such as Panorama.

Limitations: The technologies used by FACTS are outdated in that is it not conducive for other systems to interface with it nor does it possess document storage capability.

Future Contingencies: Certain aspects of FACTS functionality, such as inspections (near term) and recall related assignments (long term), may be retired in the future as shared service components become available and other systems can begin performing and tracking operations.

Notes: It should be noted that in FACTS a single assignment may be used to generate multiple operations (e.g. more than one inspection, or an inspection and a sample collection, etc.)

Data Elements: See Figure 1 and Figure 2 below.

Figure 1: The FACTS “Create Assignment” Screen

Data Elements:

Assignment Section

Field Name Field Description

Requesting Organization FDA organization requesting the operation.

Requester Completion Date Date by which the work is targeted for completion by the requestor.

Priority Priority of the assignment.

Routine priority assignments should be covered when district resources allow, but generally within the next 3 - 12 months.

High priority assignments take priority over all other field work of the Center issuing the assignment. Timeframes for the completion of the assignment are established by the issuing Center and are included in the assignment.

Top priority assignments take priority over all other field work, including the work of the issuing Center, the other centers, and headquarters, due to public health or other concerns. Top priority assignments should be addressed upon receipt by the district and completed before all other district work.

ORA Reqd No longer used.

Compliance Number Number used for compliance work generated in FACTS (functionality no longer used).

Subject Free text field describing the subject of the assignment.

ORA Cncrnc Num Unique tracking number for certain operations.

Survey Num Used for tracking certain sample collection/analysis operations.

Remarks Free text field where additional notes regarding the assignment can be entered.

Reporting Method No longer used.

Background Information Free text field where background information regarding the assignment can be entered.

POC Name Point of contact for the assignment.

Operations Section

Field Name Field Description

Op Code Operation Code (i.e. the type of operation) created from the assignment e.g. (domestic inspection, foreign inspection, domestic investigation, foreign investigation, sample collection, sample analysis, etc.).

Rqstr Prty Priority assigned to the operation by the Requestor.

Subject Free text field describing the subject of the operation.

Target Date The date the operation should be completed by.

Requester Remarks Free text field where additional notes regarding the operation can be entered.

Estmtd Hours No longer used.

Estmdtd Smpl Cost No longer used.

Reimbursable Indicator of whether the work performed is reimbursable.

Accomplishing Org The FDA organization that will be get the credit of the operation.

Performing Org The FDA organization performing the operation.

PACs and Products Program Assignment Code(s) (PAC). PACs are an alphanumeric identifier for the type of work to be performed during an operation. Products are the product codes associated with the assignment.

Firms and Cross References Firms (via FDA Establishment Identifier (FEI)) associated with the assignment and other reference numbers that help identify a firm.

Lab References Sample information associated with the assignment.

Figure 2: The FACTS “Maintain Assignments” Screen - note the one-to-many relationship of assignments to operations

Panorama Overview: Panorama replaced the Establishment Evaluation System (EES) used by the Center for Drug Evaluation and Research (CDER) which captures the assignment information as well as Inspection Assignment Requests (IARs) that are sent to the Office of Regulatory Affairs (ORA) so inspections can be performed and completed.

Technology: Panorama is an off-the-shelf software.

Interfaces: Panorama interfaces with FACTS through a set of intermediate staging tables which allows creating and tracking assignments for inspection operations without manually entering the information into or accessing FACTS. Panorama uses the EES interface to push inspection assignment requests and associated information to FACTS.

Future Contingencies: Panorama is currently operational and therefore must be considered during decision making processes concerning assignments.

Data Elements: Assignment data received in Panorama is the same as displayed in the FACTS assignment screens above. The fields necessary for Panorama to populate an IAR, in addition to the assignment information, are found below in the FACTS screen displaying IAR information received from EES.

Figure 3: The FACTS “Inspection Assignment Request” screen

IAR Section

Field Name Field Description

Assignment ID Assignment ID given to the request sent by Panorama.

Operation ID Operation ID given to the operation created from the FACTS assignment.

Application A display only field sent from Panorama from EES.

Applicant A display only field sent from Panorama from EES.

Address A display only field sent from Panorama from EES.

PDUFA Ind A display only field sent from Panorama from EES.

PDUFA Date A display only field sent from Panorama from EES.

District Goal Date A display only field sent from Panorama from EES.

Drug Name A display only field sent from Panorama from EES.

Strength A display only field sent from Panorama from EES.

Dosage Form A display only field sent from Panorama from EES.

Desc A display only field sent from Panorama from EES.

FEI A display only field sent from Panorama from EES.

Name A display only field sent from Panorama from EES.

Phone No A display only field sent from Panorama from EES.

FAX A display only field sent from Panorama from EES.

Email A display only field sent from Panorama from EES.

Request Type A display only field sent from Panorama from EES.

Profile Code A display only field sent from Panorama from EES.

Profile Description A display only field sent from Panorama from EES.

Product Specific Inspection Criteria

A display only field sent from Panorama from EES.

Drug Master Files A display only field sent from Panorama from EES.

Responsibilities – Stage A display only field sent from Panorama from EES.

Responsibilities – Process A display only field sent from Panorama from EES.

Reference Application Number A display only field sent from Panorama from EES.

Comments A display only field sent from Panorama from EES.

Role A display only field sent from Panorama from EES.

Name A display only field sent from Panorama from EES.

Planned Start Date Date entered by the Supervisor for when the work is planned to begin.

Planned Completion Date Date entered by the Supervisor for when the work is planned to be completed.

eNSpect Online Overview: eNSpect is used to manage the ORA inspection and investigation processes. The online component is used by Supervisors to create assignments and to assign inspections and review the results and related documentation. The offline component is used by Investigators to perform their inspections in the Field. Most foreign and domestic inspection and investigation operations have been moved from FACTS into eNSpect. eNSpect can create assignments for inspection and investigation operations and support the inspection/investigation process.

Technology: eNSpect Online uses a web-based interface to read and write to tables in an Oracle database. Documents associated with assignments are stored as binaries in the eNSpect database and transferred into Documentum (e.g. a doc base) when the inspection operation is completed. The proposed service shall continue to allow the web-based online version of the eNSpect interface to interact with assignments.

Available Services: eNSpect relies on data services provided by:

1. Document Generation Services/DGS – Service used to create documents with templates and populating fields of those templates with information stored in the database.

2. Firm Management Services/FMS – Service to add, update, and remove firm information from ORA’s establishment inventory.

3. Notification Service /NS – Service used to notify users by e-mail of certain trigger events in the system.

4. Standardized Evidence and Reference Services/SERS – Service to load and retrieve documents from the doc base (Documentum).

These services can potentially be leveraged in the development of the autonomous service.

Interfaces: eNSpect interfaces with FACTS nightly via an automated script. Conversely, assignments created in eNSpect are transferred back to FACTS only after the operation resulting from an assignment is completed. Data is written back to FACTS because reporting systems utilize FACTS data rather than eNSpect data directly.

Future Contingencies: Screens in FACTS will be decommissioned in the future, with functionality likely being migrated to other systems. Although the FACTS database is likely to remain in use, former FACTS functionality will still need the ability to create assignments and assign them to organizational users.

Data Elements: There are similarities between the way assignments can be created and the types of data collected by both eNSpect and FACTS during the assignment creations process. However, eNSpect allows for the association of documents to the assignment, where FACTS does not. eNSpect only allows one assignment to create a single operation, where FACTS created assignments can be associated with multiple operations. Despite this limitation, the fields below should be taken into consideration when determining what data should be collected during the assignment creation process (required fields are notated with an *).

Additional fields related to the completion of the assignment, such as the date the assignment was completed, are populated when the system responsible for conducting the operation (in this case an application called eNSpect Field Client) completes the work.

Figure 4: Page 1 of Assignment Creation in eNSpect Online – Overview

Field Name Field Description

Subject Free text field describing the reason, firm, assignment, or project, etc. which the operation is for.

Operation Type Type of operation the assignment is for (e.g.

domestic inspection, foreign inspection, domestic investigation, foreign investigation).

Target Date The date the operation should be completed by.

Priority Priority of the inspection.

Routine priority assignments should be covered when district resources allow, but generally within the next 3 - 12 months.

High priority assignments take priority over all other field work of the Center issuing the assignment. Timeframes for the completion of the assignment are established by the issuing Center and are included in the assignment.

Top priority assignments take priority over all other field work, including the work of the issuing Center, the other centers, and headquarters, due to public health or other concerns. Top priority assignments should be addressed upon receipt by the district and completed before all other district work.

Requester Completion Date Date by which the work is targeted for completion by the requester.

Concurrence Number Unique tracking number for certain operations.

CMS Case ID The case id from the Compliance Management System (CMS) that relates to the inspection.

Basis Drop down list of reasons for the inspection (e.g. surveillance, follow-up to a warning letter, etc.).

Reimbursable No longer used.

Requesting Organization FDA organization requesting the operation.

Point of Contact Point of contact for the assignment.

Instructions Free text field with instructions (if any) specific to the assignment.

PAC Program Assignment Code(s) (PAC). PACs are an alphanumeric identifier for the type of work to be performed during an operation.

Figure 5: Page 2 of Assignment Creation in eNSpect Online – Firm

Field Name Field Description

FEI (FDA Establishment Identifier) Numeric identifier of a firm.

Firm Name Name of the firm based on the FEI found in ORA’s firm database.

Firm Address Address of the firm based on the FEI found in ORA’s firm database.

Other Work at this Firm Displays other assignments associated with the firm.

Figure 6: Page 3 of Assignment Creation in eNSpect Online – Attachments

Field Name Field Description

Document Type Type of document being uploaded. The list of documents is a pre-defined list (e.g. 482s, notes, etc.).

Description Free text field for extra information regarding the documents.

Figure 7: Page 4 of Assignment Creation in eNSpect Online – Assign

Field Name Field Description

Accomplishing Org: The FDA organization that will get credit once the assigned operation is complete.

Performing Org: The FDA organization performing the assigned operation.

Associate Org: The FDA organization associated with the assigned operation, which grants the selected org editing rights to the operational record.

Select Recipient: FDA user of the selected Performing organization to which notification of the assignment should be sent.

Comments: Free text field with comments regarding the assignment.

Created assignments and their status can be searched and viewed in the eNSpect Online interface.

Figure 8: eNSpect Online Assignment List and Search Screen