Attachment2PharmacoviglianceTO_SOW.docx

Version: 1.0 Error! Unknown document property name.

16-223-SOL-00079 Page 8 of 18 CFSAN COTS Pharmacovigilance Software, Maintenance, Configurations, and Support CFSAN Adverse Event Management System (CAEMS) Attachment 2: Task Order SOW

Food and Drug Administration

Center FOR Food Safety and Applied Nutrition

Attachment 2: TASK ORDER 1 Pharmacovigilance COTS Application Implementation and Support

Statement of Work (SOW)

Version: 1.0 Error! Unknown document property name.

Revision Date: Error! Unknown document property name. Page 2 of 18 Attachment2PharmacoviglianceTO SOW.docx

Introduction

1.1 Background

The purpose of this task order is to implement a new COTS product to support the collection and management of AE data to a subgroup of OAO super users and other FDA end users.

The CFSAN Adverse Event Reporting System (CAERS) centralizes Center adverse event (AE) report management activities. Case records are created by data entry users from paper and PDF format reports, and automatically from AE report data in other FDA IT systems. The various non-electronic submission content types are primarily MedWatch Forms (3500/3500A/3500B), medical records, and Safety Reporting Portal (SRP) rational questionnaire PDFs. Once created, populated, and coded cases are made available to case safety reviewers, downstream data analysis systems, and the public through Freedom of Information Act requests.

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

CAERS adds value to each AE report by digitizing paper-submitted report data, assigning standard medical symptom terminology, product ingredients not included by submitters, and minor edits for readability. Finally, the system notifies the appropriate user or group about each case, ensuring that CFSAN program offices and resources are only spending time evaluating those cases that pertain to their work. All cases are accessible by all users, easing the sharing of case information between users when needed. CAERS provides correspondence generation and management functionality for communications with report submitters.

As a custom developed application largely unchanged since 2003, CAERS is complex and expensive to maintain or modify due to years of minor functionality changes and technology upgrades. The CAERS application user interface (UI) is unintuitive and inefficient. It lacks features offered by modern systems, such as XML based case creation, robust and automated data standardization, and data entry tools like autocomplete and spell check. As a result, only subsets of the data are clean and complete enough to be included in signal detection statistical analysis, and data cleanup is required for almost all review projects. Data entry consumes more than $1 million annually. While a web-based public facing adverse event report submission system exists in the Safety Reporting Portal, the SRP covers only dietary supplement AERs and there is no integration to the CAERS. Reports received through this site must still be entered into the CAERS manually, and operations and maintenance for the SRP is costly.

The CAERS currently supports approximately 50 users in the following capacities:

CFSAN needs a COTS product, to be named the CFSAN Adverse Event Management System (CAEMS), to replace its current CAERS which supports CFSAN’s current needs for AE management with improved usability, data standardization capability, greater automation to reduce data entry requirements, and reduced operations and maintenance costs. The product must also provide an integrated, public facing AE report submission system that minimizes the time and effort needed for consumers and industry to report AE data regarding all CFSAN product types.

1.2 Objectives

Implement a COTS solution to replace the legacy CAERS that will improve the quality of consumer and industry supplied adverse event report data, streamline and create efficiencies in business workflow processes and reduce overall operations and maintenance costs of the AE system. The following are objectives under this task order:

· Perform project management and technical coordination for FDA CAEMS

· Implement, develop, modernize, and enhance CAEMS

· Perform operations and maintenance for CAEMS

· Provide maintenance releases for the purpose of addressing defects and maintenance issues.

· Provide help desk support for CAEMS users

· Provide all necessary COTS software, licenses, and full lifecycle support for the CAEMS solution.

· Automate CAERS workflow to reduce data entry, symptom coding and product standardization

· Integrate with electronic sources of adverse event report data (SRP, FACTS, etc.)

· Create a public facing adverse event reporting interface accessible by mobile devices

· Provide training to FDA for use of the new CAEMS 2 Scope

2.1 task order managemenT The Contractor shall provide project management oversight described in IDIQ Task Area 1 to ensure that the scope, schedule, quality, and price are monitored and controlled throughout the duration of this Task Order. The Contractor Project Manager (PM) shall provide task order, resource, and risk management. In order to ensure technical compatibility with FDA's technical environment, 508 compliance, and reduction of IT security risks, the Contractor PM shall assist in the following IT related management activities as they pertain to this Task Order: release, change control, configuration, and IT investment management.

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

2.1.1 Kick-Off Meeting

The contractor Project Manager shall host a "kick-off meeting" within seven working days of award. The meeting may be held remotely or onsite. The purpose of the kick-off meeting is to introduce the Contractor staff including the key personnel to the COR and the FDA CAERS stakeholders and discuss the Contractor's approach to meeting the requirements of this Task Order SOW.

2.1.2 Project management Plan

The Contractor shall provide a Project Management Plan (PMP) to the COR describing the technical approach, organizational resources and specific roles, communication approach, quality control, risk management, change management, configuration management, release management, integration management, deliverable management, system user story backlog (defined in section 2.3.1), and project milestone schedule, to be employed to meet the cost, performance, quality, schedule and deliverable requirements throughout this task order execution.

The PMP shall be delivered within 30 days of award. The Contractor shall provide a system backlog composed of user stories and divided into epics within 30 days of award. Each user story will have the associated information described in section 2.3.1, “Requirements Activities” by the end of sprint 0. The Contractor shall develop a Project Schedule which shall be completed in accordance with Project Management Institute(PMI) standard practices, and incorporate all deliverables, EPLC milestones and stage gates as drafted in the Project Process Agreement (PPA). The PMP shall include a communication plan that identify roles and responsibilities of FDA personnel, contractors, and subcontractors and submit to the COR for approval within 15 days of task order award.

2.1.3 Monthly Progress Reports

The contractor Project Manager shall provide weekly status reports to the FDA COR or Project Manager. Formal monthly status reports shall be delivered to the COR in accordance with the delivery table at the time on or before the 10th of the calendar month following the reporting month. Status reports shall include:h

· The overall progress of the project

· Progress on deliverables against the project plan

· Identified risks and mitigation strategy

· Accounting for deliverables

· Action items for the following period

· Any current or anticipated problems with scheduled activities

· The status of the previous month's invoice

2.1.4 Final Report

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

2.1.5 EPLC Support and Documentation

The Contractor shall support the FDA EPLC process. Within one month after the Task Order award, the Contractor Project Manager shall provide a signed FDA EPLC Project Process Agreement (PPA) to the COR for each release.

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

· Project Schedule

· Project Management Plan

· System Requirements Specifications

· System Design Document

· Data Model

· Release Test Plan

· Test Cases

· Requirements Traceability Matrix

· Test Report

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

The contractor shall use the following FDA tools for activities under this task order:

· HP ALM for requirements management

· HP Quality Center for test cases and associated requirements

· JIRA for change requests and defect tracking

· SubVersion for release code management

2.1.6 Release Development and Management

The contractor shall work with OIM to support the development and deployment of system releases to the appropriate Data Center environments. The FDA categorizes releases as Initial, Major, Minor, or Emergency/Patch. These release types are defined as:

· Initial Release: Scheduled first release of a new system.

· Major Release: Scheduled release to include major enhancements, and/or redesigns, technology upgrades, and defect corrections.

· Minor Release: Scheduled release to include defect corrections and/or minor enhancements, including software changes necessary to support system or Commercial-Off-the Shelf (COTS) patches.

· Emergency Release: Release to correct one or more problems with a system that is negatively impacting functionality and requires prompt resolution. Emergency Releases are added to the project schedule as needed upon approval by COR and/or Project Manager).

The contractor is expected to participate in the Change Control Board (CCB) process. The Contractor shall ensure compliance and follow the established change control process that identifies and assesses potential changes to existing production systems for all releases. The change control process includes technical assessment, estimation of recommended changes, and participation in CCB meetings.

For each release, the contractor shall follow established EPLC policies to ensure the implementations of these are in accordance to standards acceptable to the government. For emergency releases and corrections to production data, it will be required as needed and/or depending on the criticality of the data usage and error.

The contractor shall perform the following activities for Release Development and Management:

· Prepare and present level of effort estimates, root cause analysis, and technical evaluation for all change requests and minor enhancements. The technical evaluation shall include analysis of related impacts (if any) to the system that interface with the one that is being modified. Support the CCB to obtain approvals for each defect resolution and enhancement to be included in a release, and to determine the overall content of each release.

· Provide project Schedule for all releases. Plan, develop, test, and implement all releases in accordance.

· Plan and support User Acceptance testing. Support included provide user test scripts; facilitate testing; review and verify test result; and make changes as agreed upon by FDA COR.

· Submit and track release requests for Development, Test, Pre-Production, and Production environments following FDA procedures for submission of infrastructure change requests.

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

· Work with data center contractors to support production releases which are normally scheduled outside of normal business hours as needed. Production releases are sometimes required to continue into the weekend and there could be multiple releases scheduled for the same day. Deployment of production releases includes validation that the implementation was completed and the software is working as intended in the production environment.

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

2.1.7 Communication Management

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

2.1.8 Meetings

As an integral part of its task order management, the contractor shall prepare materials for and participate in or lead briefings, meetings, and other interactions with multiple FDA government points of contact for specific activities regarding project progress, issues, and concerns as directed by the COR. The contractor shall participate in meetings in different capacities such as coordinating meetings, facilitating or leading discussions, contributing questions and answers, raising issues, risks and concerns, developing and giving presentations, and other active oral and written communications.

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

It is anticipated that status meetings will be held on a weekly basis. Sprint planning meetings will precede each sprint. In addition to these regular meetings, it is expected that some sprint zero specific meetings will be required to create the system user-story backlog, coordinate technical environment setup, and for other project initiation activities. Stage gate reviews will occur throughout the project during periodic hardening sprints, and their frequency will be determined during sprint zero. The contractor shall also coordinate Task Order review meetings as directed by COR, to discuss the status, progress and any issues regarding the Task Order.

2.2 software licenses In accordance with Task Area 3 of the IDIQ, the contractor shall provide COTs Pharmacovigilance Software Licenses and associated maintenance. The licenses shall support 20 users during sprints for initiation and planning, and development and implementation of CAEMS. It is anticipated the users will assist in identifying additional features and functionalities to successfully migrate legacy CAERs data to the new COTs product. In addition, they participate in user testing and be available to participate in the requirements gathering phase.

The contractor shall collaborate with FDA systems administrators at ADC to ensure the licenses are installed and available to the end users within one month of task order award.

The contractor shall provide technical support for the system and users licensed as described in section 2.6.

2.3 Initiation and planning (sprint 0)

The IDIQ Task Area 3 describes how the contractor will work with current CAERS stakeholders and the COR to plan the structure of development cycles and the work to be completed in them. Work in sprint zero also includes provisioning the hardware and software environments that the system will be deployed to. The contractor will also assist the business stakeholders in developing a plan for migrating data and decommissioning the current CAERS once the development schedule has been created.

2.3.1 Requirements Activities

FDA has provided high level business requirements for the system to be implemented in the file “Product Features and Functionalities Table”. The contractor is expected to work with current CAERS stakeholders to refine business requirements in preparation for development sprints. The contractor shall:

1) Review the high level requirements in the “Product Features and Functionalities Table” file

2) Conduct activities to create user stories for the system backlog, organized into epics. Defining and documenting functional and non-functional requirements, each User Story should be composed of:

a. Title

b. “As a…” statement describing functionality for the role to utilize it

c. Description of the steps required to support the functionality, with acceptance criteria for each sub step

d. Level of effort

3) Obtain approval from COR for backlog

4) Work with COR and FDA team to establish a sprint planning process, including

a. Change request governance processes to be used in sprint planning

b. Approval process for sprint scope

5) Conduct a Stage Gate Review When the Stage Gate Review is passed the project will begin development sprints, configuring and customizing the vendor product to fulfill FDA requirements.

2.3.2 Technical Environment Provisioning

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

· Deliver Requirements Specification Document and Requirements Traceability Matrix. The contractor shall work with COR and CAERS business SME to get approval/sign-off for the requirements and shall make necessary changes, if needed.

· Submit Request for Change (RFC), Server provisioning, Firewall Access & Load Balancer requests and Target State Diagram for Development, Test, Pre-prod and Production environments.

· Work with infrastructure and security teams to configure system environment for each release, in all environments: Development, Test, Pre-Production, Production Additionally, the contractor shall support FDA resources to:

· Document of the infrastructure requirements, including hardware, software, and security.

· Define the solution architecture.

· Use FDA’s RQST-IT system to request new technology, software, tools, and hardware for CAEMS

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

· Obtaining an Authority to Operate (ATO) for CAEMS, updating with each production release.

2.4 Development and implementation

In accordance with Task Area 4 of the IDIQ the contractor shall provide development and enhancement activities. Specifically, the contractor shall work within the bounds of the FDA EPLC process to document, configure, develop, test, release, and manage deliverables and software throughout the project. Work will be broken into sprints, delivering a working and enhanced build at the completion of each.

The contractor shall:

· Provide customization based on FDA requirements

· Adhere to all EPLC documentation and process requirements

· Provide seamless version upgrades, to include new functionality and preserve customizations

· The Contractor shall prepare and host design reviews for FDA program team members to review and approve the proposed design.

· The Contractor shall perform custom development where appropriate - for example for interfacing with legacy systems at FDA.

· The Contractor shall ensure acceptable system performance for LIMS releases.

· The Contractor shall perform implementation activities for bringing accepted systems and functionalities into production.

· The Contractor shall create and store logical and physical data models in FDA's ERWIN instance for configuration management of the database models.

· The contractor shall document testing scripts and plans with sufficient detail to capture end-to-end processes and functions for detailed, thorough testing of complex business processes

· The Contractor shall provide test reports, test scripts, use cases, functional check lists, and acceptance test scripts for FDA acceptance of CAEMS. The types of testing referred to is: functional, system, 508, automated regression and performance testing

2.4.1 Development Sprints

The contractor will work with the COR and according to FDA requirements to schedule development sprints, choosing user stories to develop, etc., in accordance with change request processes developed in sprint 0.

The contractor shall design, develop, test, and deploy the updated version of the CAERS application per the captured requirements using an Agile development methodology. Depending on the sprint, the application shall be deployed to the FDA WODC and/or ADC environments (Development, Test, Pre-production, and Production). All developed versions will be deployed to Development and Test. Versions produced during hardening sprints will be deployed to ADC in pre-production and production.

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

2.4.2 Hardening Sprints

The contractor shall periodically conduct hardening sprints where additional user acceptance activities are performed, including user acceptance testing and involving SGR critical partners in Sprint review (formal stage gate review). For a description of stage gate reviews, see section 2.1.5 "EPLC Support and Documentation". At the conclusion of these sprints, the application will be deployed to the pre-production and production environments by coordinating with the contractor team at ADC.

2.4.2.1 DeploymentS

In the course of each sprint beyond zero, the contractor shall test and implement the modified COTS solution within the FDA environment which includes adhering to requirements for deploying the technical solution to FDA’s development, testing, pre-production and production environments.

For Pre-Prod and Production deployments, the contractor shall work with the IT PM and ADC HP resources to perform release activities as described in section 2.1.6.

2.5 Migration of data

IDIQ Task Area 5 covers activities related to migrating data and transitioning CFSAN from legacy CAERS to the CAEMS. The current CAERS project team has documentation describing the data managed by the system. This information will be reviewed further and submitted during initiation/Sprint Zero. The contractor will use this to plan the migration of current CAERS data to the new CAEMS, and the decommission of current CAERS.

CAERS data is considered mission critical and thus requires protection from disclosure, alteration and loss. The adverse events and complaints entered into the CAERS system contain personally identifiable information (PII) and protected health information (PHI). The current CAERS System Design Document (SDD) details how the system handles data privacy.

Contractor shall:

· Provide a transition plan for migrating existing CAERS data and decommissioning CAERS, to be included in the project management plan.

· Execute the data migration plan to bring CAERS data into the new system.

· Support CFSAN administrative decommission and transition activities such as providing input on OMB PRA submissions and guidance documents

2.6 Operations and TECHNICAL support activities

In accordance with Task Area 6 of the IDIQ, training, helpdesk, and IT lifecycle support shall be provided by the contractor.

2.6.1 TRAINING SUPPOrT

Training sufficient to prepare users to use the CAEMS unassisted will be necessary for an effective transition. The Contractor shall:

· Design, create and deliver training to end users

· Provide training for approximately 15 end-users on the COTS solution.

· Provide user manuals for the different user roles supported by the system

· Provide supplemental training on changes made for each major release of the system.

2.6.2 Helpdesk

The Contractor shall provide help desk development, including development of an escalation process (ie. Tiers) and will be responsible for Tier 1 (see below) technical assistance to CAEMS Program Team and CAEMS users. The Contractor will coordinate and address inquiries through a dedicated telephone and email service. In general, the Contractor shall operate the Help Desk by performing such technical and administrative services as taking phone inquiries and responding to email or other inquiries, documenting and triaging problems, communicating with FDA Subject Matter Experts (SMEs) and escalating issues to the appropriate FDA business units when necessary. The contractor shall also produce reports explaining problem resolution, metrics, and an inventory of inquiries. Maintain issue tracking in JIRA to record all technical support interactions. The contractor shall maintain an electronic version (living document) of all questions and FDA responses received through these desk support services.

Specifically the Contractor shall:

Provide a centralized Help Desk capability.

· Working hours for the purpose of standard are 6 a.m. to 8 p.m. EST, Monday through Friday, excluding government holidays, with surge support pending written approval by the COR. When identified, occasional on-call availability for urgent situations will include after-hour weekday or weekend hours.

· Operate a HelpDesk by performing services such as: documenting, data entry, triaging issues, taking telephone calls, utilizing email and/or a queue to obtain, respond to, and close request from users and other inquiries in a timely manner.

· Gain knowledge of the systems through training, exploration, and experience to provide responses to inquiries and to aid in resolving technical and nontechnical issues.

· The contractor shall provide weekly status reports to CAEMS management regarding helpdesk metrics on all contacted issues and resolutions. Attend meetings as needed to provide status about the helpdesk task related activities.

· Create, update, modify, and provide an FAQ inventory from all inquiries.

· Develop and continually improve an issue and response tracking process in coordination with key business area partners.

· Maintain Tier 1 and Tier 2 support for all inquiries.

· Tier 1 – Issue can be answered from knowledge base or internal Helpdesk resources by the contractor. Should be passed up to Tier 2 if SMEs are required for evaluation.

· Tier 2 – Request requires Subject Matter Experts (SMEs) from the contracting team to analyze and resolve the issue.

· The contractor shall coordinate, collaborate, and provide documents to O&M support (Tier 3), data centers, users, and SMEs for timely resolutions of submission issues.

Develop documentation to guide interactions with users based on experience obtained during prior interactions with users.

· Develop and periodically update Standard Operation Procedures (SOPs) to document appropriate responses to questions or issues so that consistency of responses is achieved.

· Develop and periodically update Frequently Asked Questions (FAQs) or how-to guides to be published (SharePoint) so that users can help themselves when possible.

2.6.3 IT Lifecycle Support

The contractor will be responsible for maintaining the deployed system to keep it operational and in compliance with FDA EPLC and other policies by:

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

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

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

· Conducting System Administration activities;

· Conducting issue identification and management;

· Conducting release management;

· Developing test plans and conducting tests;

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

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

· Conducting performance monitoring and tuning;

· Monitoring data quality and conducting quality assurance;

· Providing back-up and recovery support;

· Providing data quality management;

· Providing integration and interface support;

· Providing technical support helpdesk services to end users

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

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

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

3 Period of Performance and Payment Schedule

3.1 Period of Performance

The period of performance will be one year from the date of the Task Order Award.

4 Place of Performance Place of performance is off-site at Contractor location. However, the Contractor shall be required to periodically interact with FDA staff at FDA facilities in the Washington DC metro area and surrounding areas including, but not limited to, College Park, MD; Beltsville, MD; White Oak, MD; Gaithersburg, MD; and Ashburn, VA. FDA is not required to reimburse the Contractor for attending events in the Washington DC metro and surrounding area. Hoteling office space may be available to Contractor staff when working at College Park, MD or Gaithersburg, MD.

5 Key Staff and changes to key staff The Contractor’s Project Manager and Software Developer shall be the designated Key Personnel in pursuant to Health and Human Services Acquisition Regulation (HHSAR) Clause 352.242-75, Key Personnel.

6 Deliverables The contractor shall provide the deliverables specified in the CAERS IDIQ. Additional deliverable specific to this task order are specified below.

Table 3. Task Order Deliverables

Quantity and / or frequency Review or Delivery Date

7 Government Furnished Equipment/Government Furnished Information FDA will provide the Contractor with any updated documented standards and policies including FDA Office of Information Management (OIM) Policy and Guidance, Office Policy, and IT security policies for which the Contractor is expected to comply.

The FDA will provide the following hardware when required per task order requirement:

· FDA laptop or equivalent The Contractor shall maintain a formal inventory of any Government furnished equipment and at a minimum shall track property number, equipment type, and assignee.

Access for the Contractor to the WODC, CHDC, and Wiley environments will be based on the minimum level needed to perform the tasks and the determination of FDA IT Security. Security access badges are to be used only for the purposes of accessing FDA facilities, networks, and PCs. At the end of the period of performance or termination of the contract, or termination of an employee, the Contractor must return the badges and any other Government owned property. Access to FDA systems is contingent on successful completion of the badging process; it should be started as soon as possible after award.

8 Government Points of Contact Contracting Specialist:

Xxx xxxxxxx 5630 Fishers Lane Room 1075, HFA-500 Rockville, Maryland 20857 E-mail: xxx.xxx@fda.hhs.gov

Contracting Officer Representative xxx 5100 Paint Branch Parkway Room xxx College Park

MD 20740

xxx-xxx-xxxx Email: xxx

9 CONTRACT TYPE

Purchase of the Licenses is Fixed Price and the services portion of the contract is Labor Hour.

10 Option to Extend Services 52.217-8 – Option to Extend Services (Nov 1999) The Government may require continued performance of any services within the limits and at the rates specified in the contract. These rates may be adjusted only as a result of revisions to prevailing labor rates provided by the Secretary of Labor. The option provision may be exercised more than once, but the total extension of performance hereunder shall not exceed 6 months. The Contracting Officer may exercise the option by written notice to the Contractor prior to task order expiration.

(End of Clause) Revision Date: Error! Unknown document property name.

image1.png