Attachment 4 CSTAR Task Order 3 SOW.doc

Attachment 4

Task 3 – Legacy Premarket Replacement (Labor Hour) Background Before a medical device may be marketed in the U.S., a company must obtain FDA clearance. Typically, marketing clearance is obtained by submitting an application, which is known as a premarket submission, to FDA’s Center for Devices and Radiological Health (CDRH). In specific circumstances, companies may also request device exemptions from the FDA. All premarket submissions and exemption requests must include at least one paper copy sent to the CDRH Document Control Center (DCC), which is also known as the Document Mail Center.

Upon receipt in the DCC, premarket submissions are officially date stamped and logged into a computer database where a unique control number is assigned. If the submission is a 510(k), PMA, Modular PMA, 513(g), or PDP, the database program will first check another system to ensure user fees have been paid. Next, the database program will assign the premarket submission a due date and sequential position in the review queue based on the receipt stamp date. Finally, the database program will generate an "acknowledgment letter" with the assigned control number. The acknowledgment letter will be sent via postal mail to the contact person identified in the premarket submission. The acknowledgment letter is not a marketing clearance letter; it is only an acknowledgment of receipt of the premarket submission by FDA.

The aforementioned “computer database” comprises CDRH’s legacy premarket data entry applications and databases. The legacy premarket data entry systems—which are used to log in and close out submissions—were created in the early 1990s using Oracle Forms technology. Each submission type has its own database schema, within one large CDRH database, and its own set of data entry forms. There are over 250 data entry forms that support the premarket applications, including shareable forms that collect company name and address information. Each premarket data entry system has a wide range of options to handle the submission-specific requirements. The following submission types (and associated data entry applications and databases) represent the premarket landscape:

· 510(k) – 158,000

· Third Party – type of 510(k) with a separate database schema, separate list of accredited companies, separate business rules, and no user fees

· De Novo – subset of 510(k) with separate business rules

· PMA – 25,000

· PMA-GMP – 6,000

· Modular PMA - 400

· Pre-IDE – 8,000

· IDE – 7,800

· HDE – 500

· PDP – maintained in a spreadsheet

· 513(g) – 2,300

· Master Files – 1,800

Note: The aforementioned numbers approximate the number of original submissions received by FDA over time and do not include supplements, amendments, etc. For additional background information on premarket submissions, please visit http://www.fda.gov/.

Objectives

Over the past 20 years, CDRH has not modernized the technologies behind the premarket data entry applications and databases. This has resulted in difficult-to-maintain code, inefficient business processes, labor-intensive Oracle upgrades, limited reporting and auditing capabilities, reduced data quality, and the inability to respond to change quickly.

The primary objective of this task is the modernization, in terms of reliability; functionality; quality; and technology, of CDRH's premarket data entry applications and databases. The project also will include improving the efficiency of processing paper submissions, developing all required interfaces to CDRH-owned systems, and migrating data between legacy systems and modernized systems.

At a minimum, the contractor shall work with designated government personnel to meet these specific objectives:

Database Architecture and Design

· Create an integrated database that handles current submission types with the flexibility to accommodate future types;

· Design a data model that captures the history of changes and forms the basis of a comprehensive audit trail;

· Construct a system that enables additional structured data to be captured more easily;

· Devise an architecture that accommodates both DCC data entry and/or data submitted by industry electronically;

Data Entry

· Replace legacy data entry forms and applications with modernized user interfaces;

· Provide administrative interfaces for editing and maintaining data and records without the need to access databases directly;

· Externalize business rules from the system code and make accessible to program management (business users);

System Interfaces

· Update read/write interfaces to and from other systems in the CDRH CSTAR suite of applications (i.e., CTS and CARS);

· Facilitate necessary changes to legacy databases and systems (e.g., PREDICT, OSCAR, MDUFMA);

· Provide technical support—related to the replacement of CDRH’s premarket databases and applications—to the teams that maintain the FDA User Fee and Financial Reporting System and FDA Unified Registration and Listing System;

· Create document generation modules for mailing official correspondence and generating routing slips;

Reporting and Searching

· Develop reports for Program Operations Staff (POS) and DCC personnel;

· Implement an ad-hoc querying capability that can be accessed by CDRH staff;

Data Migration

· Migrate data from legacy premarket databases to the modernized database;

· Work with program offices and data owners to perform cleanup on data as it is migrated;

Business Process Reengineering

· Model the “as is” business processes associated with the premarket submission type(s) that will be replaced under this task;

· Make recommendations about ways to improve efficiency and productivity with regard to the paper-based routing processes.

Description of Work

In conjunction with all relevant terms, conditions, requirements and guidance of the CENTER SUBMISSION TRACKING AND REPORTING contract, the contractor shall analyze, document, design, develop, test, and implement a FDA-specified solution, according to EPLC and FDA IT standards. These practices also include the use of software development life cycle tools, including JIRA (change requests), Subversion (source code), and Traction (documentation). Overall Program Management (PM) support shall be provided throughout the performance period using internal processes consistent with principles outlined in the Project Management Institute’s (PMI) PMBOK® Guide.

The Government seeks an initial operating capability (IOC) that results in a new, integrated database architecture and the replacement of one (at a minimum) of the premarket data entry applications. Replacement includes migrating data between the legacy and modernized databases, updating required system interfaces to connect to the new database(s) and application(s), and providing basic reporting capabilities.

To achieve the IOC goal, the contractor’s work shall be performed in accordance with tailored EPLC processes and templates, including Stage Gate Reviews. For this task, the contractor shall be required to perform the following work, in an iterative fashion, for these FDA EPLC phases:

1. Initiation, Concept, and Planning (ICP) Phase

Within the FDA EPLC framework, the Initiation Phase, Concept Phase, and Planning Phase shall be combined into a single “ICP” phase. The purpose of this combined phase is to: 1) Identify significant assumptions and constraints on solutions relative to the business need; 2) Explore alternative concepts and methods to satisfy the need; and 3) Develop and establish the business requirements. The contractor shall be required to perform the following work, based on the Objectives, in this phase:

· Establish a Project Management Plan;

· Develop the Project Schedule;

· Plan, schedule, lead, and document the business requirements gathering and business process modeling sessions to ensure all significant business requirements are captured;

· Create a Business Requirements Document (BRD) to gather business requirements as a basis for the system requirements;

· Develop, maintain, and validate a Glossary of Terms (vocabulary);

· Schedule, facilitate, and document the outcome of reviews and sign-off meetings with the Integrated Project Team (IPT) and business community;

· Create a list of feasible alternative technical solutions that may include custom coding, commercial-off-the-shelf (COTS) technologies, government-off-the-shelf (GOTS) systems, or a combination of the three;

· Schedule and facilitate a preliminary review of all technology alternatives with the FDA COTR/Project Manager, CDRH business management, IPT, and other identified stakeholders;

· Provide input in security documentation created by FDA Office of Information Management (OIM) staff;

· Hold a Stage Gate Review to ensure the project passes the exit criteria of critical partners before proceeding to the next phase.

2. Requirements Analysis Phase

The purpose of the Requirements Analysis phase is to validate and decompose the business requirements into functional and non-functional system requirements. These system requirements will further define the product in more detail with regard to inputs, processes, outputs, and interfaces, providing the basis for alternative technical solutions. The contractor shall be required to perform the following work, based on the Objectives, in this phase:

· Plan, schedule, lead, and document the system requirements gathering sessions;

· Create a Systems Requirement Specifications (SRS) document to capture the functional and non-functional requirements, including reporting requirements for POS and DCC staff;

· Supplement the validation of written system requirements using graphical means, such as, but not limited to, prototypes, context diagrams, mockups, flow diagrams, wireframes, functional decomposition diagrams, storyboards, use cases, scenarios, etc;

· Review and update the BRD for accuracy and completeness while the SRS is being developed;

· Identify dependencies to other systems and interfaces;

· Evaluate existing data sources to prepare for data cleanup and data migration into the new, modernized database;

· Develop, validate, and maintain a Data Dictionary;

· Design and validate the Logical Data Model;

· Schedule, facilitate, and document the outcome of reviews and sign-off meetings with the Integrated Project Team (IPT) and business community;

· Hold a Stage Gate Review to ensure the project passes the exit criteria of critical partners before proceeding to the next phase.

3. Design & Development Phase

Within the FDA EPLC framework, the Design Phase and Development Phase shall be combined into a single “Design & Development” phase. The purpose of this combined phase is to develop detailed design specifications, emphasizing the physical solution, which will be transformed into machine-executable form. The solution will ensure that all of the individual components of the business product function correctly and interface properly with other components. The contractor shall be required to perform the following work, based on the Objectives, in this phase

· Perform the design of the system based on the detailed requirements;

· Create a System Design Document, which includes dependencies to other systems;

· Design the Physical Data Model;

· Review and update the BRD and SRS for accuracy and completeness while the system is being designed and developed;

· Update the Data Dictionary as necessary;

· Finalize planning and mapping to migrate data from the legacy database into the new database;

· Create the Interface Control Document (ICD);

· Implement the solution according to the system design;

· Ensure that the solution is 508 compliant;

· Create the System Architecture Document;

· Write the Version Description Document (VDD);

· Perform thorough unit testing of the new, modernized system;

· Create the Software Unit Test Report;

· Start developing testing artifacts (plans and test cases) for the Test Phase;

· Provide input in security documentation created by OIM staff;

· Hold a Stage Gate Review to ensure the project passes the exit criteria before proceeding to the next phase.

4. Test Phase

The purpose of the Test phase is to perform controlled and focused testing to uncover errors and bugs in the business product and to fix them before final implementation. The contractor shall be required to perform the following work, based on the Objectives, in this phase:

· Finalize the Master Test Plan and Release Test Plan;

· Finish the detailed Test Case Specifications;

· Create a Requirements Traceability Matrix (RTM) to validate the requirements;

· Perform thorough functional testing, integration testing, and regression testing of the solution;

· Start developing an Operations and Maintenance Manual;

· Fix bugs and errors uncovered during testing, re-deploying to the environments, and re-testing;

· Support user acceptance testing (UAT);

· Provide input in security documentation created by OIM staff;

· Hold a Stage Gate Review to ensure the project passes the exit criteria before proceeding to the next phase.

5. Implementation Phase

The purpose of the Implementation Phase is to install and deploy the solution in FDA’s production environment. The contractor shall be required to perform the following work, based on the Objectives, in this phase:

· With user acceptance and passed tests, deploy the solution to production;

· Migrate data from the legacy database to the new database;

· Provide post-deployment input in security documentation;

· Provide post-deployment input into a Contingency and Disaster Recovery plan;

· Finalize the Operations and Maintenance Manual (note that O&M support will be provided by government staff and contractor resources on another task order);

· Create a lessons learned document (log) and schedule a meeting with the FDA COTR/Project Manager, CDRH business management, IPT, and other identified stakeholders to review and discuss the findings.

Assumptions

1. Government personnel will continue maintaining legacy premarket data entry applications and databases until they are replaced.

2. Any recommendations from this task will be reviewed by the Government, and upon review of the recommendations, the Government will make an independent decision on whether to implement the recommendations.

3. The contractor will not make interface changes to non-CDRH systems.

4. Changes to business processes for processing and routing incoming paper submissions (original, supplements, amendments, etc.) are within scope.

5. Enhancements and modifications to premarket review business processes, including electronic submissions, are outside the scope of this task.

Key Personnel

The following is a list of key personnel and associated responsibilities that are minimally required for this effort:

· Project Manager - In addition to any qualifications required by this labor category under the contract, the Project Manager must have the following qualifications:

· Certified Project Management Professional (Project Management Institute PMP)

· Senior Systems Architect - In addition to any qualifications required by this labor category under the contract, the Senior Systems Architect must have the following qualifications:

· Knowledge/experience developing web services

· Experience in developing applications/services in a service oriented architecture (SOA)

· Database Management Specialist - In addition to any qualifications required by this labor category under the contract, the Database Management Specialist must have the following qualifications:

· Knowledge/experience designing and administering large Oracle databases

· Senior Computer Systems Analyst - In addition to any qualifications required by this labor category under the contract, the Senior Computer Systems Analyst must have the following qualifications:

· Knowledge/experience analyzing and modeling business processes using the Business Process Modeling Notation (BPMN)

Government Furnished Information/Government Furnished Equipment

FDA will provide laptops, tokens (fobs), and any essential accessories along with FDA network access along with FDA network access to all members under this task order. FDA will provide the development, test, pre-production, production and any other server based environment necessary to accomplish the stated work.

Deliverables

The EPLC deliverables were specified earlier in the Description of Work section, and in addition to those, this task requires these additional reporting requirements:

Business Management

Business Management

Business Management

Business Management

Business Management

Minutes – 3 working days following the meeting

COTR/PM

Business Management

Place of Performance

The contractor will be required to interact with FDA staff in multiple locations throughout the Washington, DC metropolitan area. All CDRH business staff is located at FDA’s White Oak campus in Silver Spring, MD. FDA’s Office of Information Management (OIM) staff is located at facilities in the Rockville, MD area. As of now, the Government expects that space for contractor staff will be available at an FDA site, but space has become more of a premium recently. Therefore, the contractor shall be prepared to work offsite at its own facility, at any point, during this period of performance.

Projected Schedule

CDRH anticipates that the period of performance for this task will be 13 months from contract award. The period of performance is based on the project start date per the EPLC framework. The Contractor shall inform the FDA COTR/Project Manager, CDRH business management, and Contracting Officer, in writing, of the official project start date.

project start date

project start date

The Government may elect to fund additional (optional) phases, which would involve the replacement and retirement of the databases and applications for other premarket submission types, at a later time.