RFQ 75D301-26-Q-00146.pdf

REQUEST FOR QUOTATIONS

(THIS IS NOT AN ORDER)

THIS RFQ X IS IS NOT A SMALL BUSINESS SET-ASIDE.

PAGE OF PAGES

1 72

1. REQUEST NO.

75D301-26-Q-00146

2. DATE ISSUED

8/17/2026

3. REQUISITION/PURCHASE REQUEST NO.

000HCRDB-2026-00146

4. CERT. FOR NAT. DEF.

UNDER BDSA REG. 2

AND/OR DMS REG. 1

RATING

5a. ISSUED BY

Centers for Disease Control and Prevention

Chamblee Campus Building 108, MS S108-4

4770 Buford Hwy

Atlanta GA 303413717

6. DELIVERY BY (Date)

5b. FOR INFORMATION CALL (No collect calls) X

NAME TELEPHONE NUMBER

AREA CODE NUMBER

H. Dale Bish (404) 498-1312

8. TO: 9. DESTINATION

a. NAME b. COMPANY a. NAME OF CONSIGNEE

c. STREET ADDRESS b. STREET ADDRESS

c. CITY

d. CITY e. STATE f. ZIP CODE d. STATE e. ZIP CODE

10. PLEASE FURNISH QUOTATIONS TO

THE ISSUING OFFICE IN BLOCK 5a ON OR BEFORE CLOSE OF BUSINESS (Date)

09/04/2026 10 AM ET

IMPORTANT: This is a request for information, and quotations furnished are not offers. If you are unable to quote, please so indicate on this form and return it. This request does not commit the Government to pay any costs incurred in the preparation of the submission of this quotation or to contract for supplies or services.

Supplies are of domestic origin unless otherwise indicated by quoter. Any representations and/or certifications attached to this Request for Quotations must be completed by the quoter.

11. SCHEDULE (Include applicable Federal, State and local taxes)

ITEM NO.

(a)

SUPPLIES/SERVICES

(b)

QUANTITY

(c)

UNIT

(d)

UNIT PRICE

(e)

AMOUNT

(f)

Project Title:

Modernized Application for Consumer and

Healthcare Provider VAERS Reporting

Questions, Quotes, and All Communication is to be with H. Dale Bish at uwo8@cdc.gov.

12. DISCOUNT FOR PROMPT PAYMENT

a. 10 CALENDAR DAYS

b. 20 CALENDAR DAYS

c. 30 CALENDAR DAYS

d. CALENDAR DAYS

NUMBER PERCENTAGE

NOTE: Additional provisions and representations are are not attached.

13. NAME AND ADDRESS OF QUOTER 14. SIGNATURE OF PERSON AUTHORIZED TO

SIGN QUOTATION

15. DATE OF

QUOTATION

a. NAME OF QUOTER

b. STREET ADDRESS 16. SIGNER

a. NAME (Type or print) b. TELEPHONE

c. COUNTY AREA CODE

d. CITY e. STATE f. ZIP CODE c. TITLE (Type or print) NUMBER

AUTHORIZED FOR LOCAL REPRODUCTION STANDARD FORM 18 (REV. 6-95)

Previous edition not usable Prescribed by GSA FAR (48 CFR) 53.215-1(a)

7. DELIVERY

FOB

DESTINATION

OTHER

(See Schedule) mailto:uwo8@cdc.gov

Section B - Supplies Or Services and Prices/Costs

ITEM SUPPLIES / SERVICES QTY / UNIT UNIT PRICE EXTENDED PRICE

0001 Modernized Application for

Consumer and Healthcare Provider

VAERS Reporting

Firm Fixed Price

Severable Services

Monthly Payments in Arrears

Period of Performance:

09/28/2026 – 06/27/2027

1 Job $ $

0002 Non-Conference Travel for

Onboarding

All travel shall be conducted in accordance with Federal Travel

Regulations.

Direct Reimbursement

1 Job $31,500.00

Estimate

$31,500.00

Not-to-Exceed

0003 Non-Conference Travel for

Meetings

All travel shall be conducted in accordance with Federal Travel

Regulations.

Direct Reimbursement

1 Job $31,500.00

Estimate

$31,500.00

Not-to-Exceed

Section C - Performance Work Statement

Title: Modernized Application for Consumer and Healthcare Provider VAERS Reporting

SECTION 1 – BACKGROUND

Vaccine Adverse Event Reporting System (VAERS) is a national early warning system for monitoring the safety of

U.S.-licensed vaccines. The Centers for Disease Control and Prevention (CDC) seeks to improve VAERS reporting for both the public and healthcare providers through a mobile-friendly, desktop-compatible web application that increases usability, improves completeness and quality of submitted information, and reduces user burden.

This acquisition supports development of a modernized reporting experience that incorporates a redesigned VAERS landing page and navigation, a guided reporting workflow with branching logic for public versus healthcare-provider submitters, an intelligent validation that assists with form completion, customer centric tooltips, informational popups and reactive design site navigation, modern / reactive popup frequently asked questions (FAQ) features.

The solution shall protect Personally Identifiable Information (PII) and Protected Health Information (PHI) and support integration with existing VAERS systems and processes. The Contractor shall comply with applicable federal information security, privacy, and accessibility requirements, including HIPAA, the Privacy Act, Section

508, and FedRAMP requirements for the CDC-managed cloud environment used to process or store VAERS data.

Contractor authorization to develop and deploy on CDC infrastructure shall be governed by an Authority to Develop

(ATD) issued by CDC in coordination with the Office of the Chief Information Officer (OCIO).

SUBSECTION A – DEFINITIONS

• ATD (Authority to Develop): Authorization issued by CDC, coordinated with OCIO, permitting the

Contractor to develop, locally test, update, and deploy the application on CDC infrastructure following review of adequate security and privacy documentation.

• ATO (Authority to Operate): is an official management decision by a designated federal authorizing official that permits an information system to operate and explicitly accepts the risk to organizational operations, assets, individuals, other organizations, and the Nation based on implemented security and privacy controls

• Branching Logic: Conditional form flow that presents or suppresses data fields based on submitter type (public

vs. healthcare provider) and report characteristics (e.g., vaccine error with no adverse event).

• EPLC: Enterprise Performance LifeCycle, comprised of Initiation, Concept, Planning, Requirements Analysis, Design, Development, Test, Implementation, Operations & Maintenance, and Disposition where applicable.

• FedRAMP: Federal Risk and Authorization Management Program.

• FISMA: Federal Information Security Modernization Act (updated in 2014).

• FITARA: Federal Information Technology Acquisition Reform Act.

• HIPAA: Health Insurance Portability and Accountability Act of 1996, as amended, including applicable

Privacy and Security Rules.

• Low-Code / Configurable UI: Application design that enables authorized CDC program personnel to make content and interface updates with limited developer support.

• OCIO: Office of the Chief Information Officer (CDC).

• PHI: Protected Health Information.

• PII: Personally Identifiable Information.

• Section 508: Section 508 of the Rehabilitation Act of 1973, as amended, and applicable HHS ICT accessibility requirements.

• VAERS: Vaccine Adverse Event Reporting System.

SUBSECTION B - CDC Cloud Environment

Hosting Environments

CDC operates in a hybrid mode, with systems locally as well as in the cloud. CDC provides access to a standard set of services on Amazon Web Services (AWS) as well as Microsoft Azure that are FedRAMP authorized.

MS Azure

CDC uses a variety of products from Microsoft Azure. These products are available from general purpose to memory intensive and high-throughput applications and are compatible with Infrastructure as a Service (IaaS) and

Platform as a Service (PaaS) models. The Microsoft Azure services available include (but are not limited to):

• Virtual Machines (IaaS)

• Azure Managed Instance SQL (PaaS)

• Azure SQL Comparison (IaaS and PaaS)

Azure SQL Database (PaaS)

Azure SQL Managed Instance (PaaS)

SQL Server on Azure VMs (IaaS)

• Load Balancers

• Private endpoints

• Storage accounts shares

• Azure Logic apps

• Azure Web apps

AWS

CDC uses a variety of products from Amazon Web Services (AWS). These products range from virtual servers to database services and are compatible with Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) models. Below is a list of the standard AWS products available, including but not limited to:

• Elastic Beanstalk

• Lambda

• DynamoDB

• Amazon Relational Database Service (RDS)

• Lake Formation

• Elastic Kubernetes Service (EKS)

• Elastic Container Service (EC2)

• DocumentDB

• Amazon Simple Email Service (SES)

• Amazon Simple Queue Service (SQS)

• ElastiCache

The full list of FedRAMP compliant products available as part of the Azure and AWS FedRAMP Audit Scopes may be considered for usage.

EDAV

Enterprise Data Analytics and Visualization (EDAV) is an Microsoft Azure cloud-based set of technologies, tools, and resources used to simplify data workflows and save time throughout the data process, from data collection to visualization and action. Services include (but are not limited to):

• Azure Data Factory

• Azure Data Lake

• Azure OpenAI API

• Azure Functions

• CDC Posit

• Databricks Data Warehouse

• CDC Chatbot based on OpenAI's GPT (Generative Pre-trained Transformer) architecture

One CDC Data Platform (1CDP)

1CDP is CDC’s unified data platform, built on Palantir Foundry Software as a Service (SaaS) technology. For more information see One CDC Data Platform | Data Modernization | CDC

SUBSECTION C – Program Management and Planning

The Government requires effective program management throughout the period of performance to ensure schedule adherence, risk mitigation, cost control, and clear communication between the Contractor and Government stakeholders.

Government Outcomes Sought:

• A well-structured, executable program management approach with proactive risk identification and mitigation.

• An agile development plan with key performance indicators (KPIs)

• Transparent, regular communication on progress, risks, staffing, and cost performance.

• A formal change control process that protects system architecture, scope, and performance standards.

• Infrastructure costs managed within an approved baseline, with explicit cost modeling.

Associated Tasks (Illustrative):

• Project Management Plan (PMP) including work breakdown structure, milestone schedule, key personnel designations, and change control process.

• Project management deliverables in accordance with federal, HHS, and CDC EPLC requirements, including appropriate documentation, coordination, and approvals at the defined stage gates and the ATD and ATO authorization gate.

• Cost Management Plan modeling compute, storage, data transfer, and ancillary service costs at target operational throughput.

• Monthly status reports covering accomplishments, schedule progress, risks, staffing changes, and actual versus planned expenditure.

• Bi-weekly technical reviews with Government stakeholders.

SUBSECTION D – Current Architecture VAERS Related Technical Information https://www.cdc.gov/data-modernization/php/one-cdc-data-platform/

The VAERS system lies within the CDC-managed MS Azure cloud environment using Azure SQL Managed

Instance databases and Virtual Machines that support the existing on-premises applications including, but not limited to ColdFusion, Tomcat, Node.js, MS .NET. Additional components include, but are not limited to Akamai, Blob Storage, Key Vault, Logic Apps and other Azure Functions. See architectural diagram on next page.

The VAERS website and reporting interface uses java and html and supports writable .pdf, CXone, and eFax.

SECTION 2 – PURPOSE/OBJECTIVE

CDC requires design, development, and deployment of a modernized, mobile-friendly, desktop-compatible web application to support both public and healthcare-provider submission of VAERS reports. The purpose of this acquisition is to:

• Simplify and streamline the reporting experience for both public and healthcare-provider submitters while improving completeness and accuracy of submitted data.

• Redesign the VAERS landing page and navigation menus to provide clearer access to reporting tools, FAQs, and data downloads.

• Provide a branching-logic reporting workflow that tailors data fields to submitter type and report characteristics, using the data elements of the current VAERS form.

• Provide intelligent completion assistance, answers user questions, and supports site navigation, with tooltips and frequently asked questions

• Provide an integrated medical record upload capability while maintaining the existing post-submission upload tool.

• Enable authorized CDC program personnel to make interface and content updates with limited developer support, using current, state-of-the-art UI/UX design principles.

• Ensure security, privacy, and regulatory compliance for all data processed, including HIPAA and Privacy

• Act protections, FISMA and FedRAMP requirements, and Section 508 accessibility, and support issuance of an ATD.

• Produce VAERS-compatible data outputs and support integration with existing VAERS systems and processes.

SECTION 3 – SCOPE OF WORK

Within the period of performance, the Contractor shall design, develop, test, and deliver a responsive, mobile-friendly, desktop-compatible web application that enables both the public and healthcare providers to submit

VAERS reports with improved usability and data quality.

The scope includes human-centered user experience (UX) design; redesign of the VAERS landing page and navigation menus for clearer access to reporting tools, FAQs, and data downloads; front-end and back-end application development; a branching-logic report submission form supporting public and healthcare-provider submitters using the data elements of the current VAERS form; implementation intelligent validation to help users through report completion, answer questions, and assist with site navigation; an integrated follow-up information upload capability; a low-code/configurable interface enabling authorized CDC program personnel to make updates with limited developer support; and production of structured data compatible with VAERS requirements to support integration with existing VAERS systems and workflows, operating within the CDC-managed hosting environment in MS Azure.

The application shall employ current, state-of-the-art UI/UX design principles.

The Contractor shall coordinate with the other existing contracts supporting the VAERS system and CDC/OCIO hosting teams to stand up the necessary environment within CDC’s cloud infrastructure, develop, and deploy the application after appropriate approvals, including issuance of an ATD.

The Contractor shall implement, document, and obtain approval for required governance stage gates, security, privacy, and accessibility controls for all data processed, including HIPAA and Privacy Act protections, FISMA and

FedRAMP requirements for the CDC-managed cloud environment, and Section 508 conformance for the application and all contract deliverables.

CDC will provide coordination, feedback, VAERS integration requirements, and access to the CDC Azure environment as applicable.

SECTION 4 – TASKS TO BE PERFORMED

Task 1: Design and Develop Mobile-Friendly, Desktop-Compatible Web

Application

1.1 The Contractor shall collaborate with CDC stakeholders to confirm functional requirements, VAERS data elements, integration constraints, and success metrics for both public and healthcare-provider reporting.

1.2 The Contractor shall produce UX artifacts (e.g., user flows, wireframes, and clickable prototypes) and incorporate CDC feedback prior to development, applying current, state-of-the-art UI/UX design principles.

1.3 The Contractor shall design and develop a responsive web application optimized for mobile devices and modern desktop browsers, enabling users to access and complete reporting from any device with internet access, including form validation, error handling, and user-friendly data entry to reduce reporting burden.

1.4 The Contractor shall redesign the VAERS landing page and navigation menus to provide clearer access to reporting tools, FAQs, and data downloads, including a link to the simplified report submission form (Task 1.6).

1.5 The Contractor shall implement a customer satisfaction survey for navigating the VAERS site.

1.6 The Contractor shall develop a mobile-friendly, desktop-compatible report submission form that uses branching logic to serve both public and healthcare-provider submitters using the data elements of the current VAERS form.

The Contractor shall:

• 1.6.1 Substitute simpler, plain-language text for the public version that requires less health expertise.

• 1.6.2 Implement branching logic so that healthcare providers submitting a vaccine error report with no adverse event (AE) are not required to complete AE-related fields.

1.7 The Contractor shall implement a pop-up customer satisfaction survey presented upon VAERS submission to measure satisfaction with the submission process.

1.8 The Contractor shall implement a low-code/configurable interface enabling authorized CDC program personnel to make content and interface updates with limited developer support, and shall document the change and configuration process.

1.9 The Contractor shall implement VAERS-compatible data capture and ability to transmit data (e.g., structured data mappings) to support integration with existing VAERS systems and workflows, as directed by CDC.

1.10 The Contractor shall implement performance optimization to achieve page load time of ≤ 3 seconds under normal operating conditions, support a median end-to-end submission time of ≤ 10 minutes for typical reports, and reduce the submission abandonment rate by ≥ 30% compared to the baseline established at project kickoff.

1.11 The Contractor shall deliver working builds for Government review and conduct iterative defect remediation through beta and final release.

1.12 The Contractor shall develop user-facing documentation and support materials aligned with the final application user experience.

Task 2: Implement Medical Record Upload and Document Management

2.1 The Contractor shall integrate an upload tool for medical record information as part of the form update, while maintaining the current upload tool for documents that become available post-submission.

2.2 The Contractor shall include a free-text box allowing submitters to provide additional information as free text.

2.3 The Contractor shall implement a tool that scans healthcare-provider submissions and suggests supplemental documents to upload.

2.4 The Contractor shall implement a two-phase approach to uploaded documents:

• 2.4.1 Phase 1 (base scope): Restrict accepted documents in the upload tool to medical records and vaccine documents related to vaccine administration or the adverse event reported.

• 2.4.2 Phase 2 (optional / future phase, not in base scope): Following Government evaluation of Phase 1, and if exercised as a future option or contract modification, allow healthcare providers to upload pictures and medical images related to the adverse event reported. The Contractor shall design Phase 1 to accommodate future Phase 2 expansion.

2.5 The Contractor shall ensure all upload and document-management functionality complies with security, privacy, and accessibility requirements for handling PHI/PII.

2.6 The Contractor shall remediate defects and optimize upload performance through beta and final release.

Task 3: Ensure Security, Privacy, FISMA, FedRAMP, HIPAA, Section 508

Compliance, and Support ATD Issuance

3.1 The Contractor shall design, develop, and document the application in a manner that protects PHI and PII and supports compliance with HIPAA and the Privacy Act for all data collected, processed, transmitted, and stored.

3.2 The Contractor shall ensure the application is developed and deployed within the CDC-managed FedRAMP-authorized Azure environment approved for use by CDC, consistent with Government security requirements.

3.3 The Contractor shall prepare and submit adequate security and privacy documentation sufficient for CDC, in coordination with OCIO, to issue an Authority to Develop (ATD) enabling local testing, updates, and product deployment on CDC infrastructure. The Contractor shall address Government review comments and remediate identified weaknesses as a condition of ATD issuance.

3.4 The Contractor shall implement and document appropriate technical and administrative safeguards (e.g., access controls, encryption in transit and at rest, audit logging, and secure configuration) consistent with CDC direction.

The Contractor shall perform application vulnerability scanning during development and before deployment to eliminate known vulnerabilities.

3.5 The Contractor shall ensure that the web application and all deliverables (including documentation) conform to

Section 508 and applicable HHS ICT accessibility standards and shall provide an Accessibility Conformance Report

(ACR/VPAT) and remediation plan for any nonconformities.

3.6 The Contractor shall prepare and submit required security, privacy, and compliance documentation identified in

Section 8, and shall address Government review comments and identified weaknesses.

3.7 The Contractor shall conduct functional, security, and accessibility testing and remediate identified defects prior to beta and final release.

3.8 The Contractor shall provide user guides and administrator/technical guides sufficient to support CDC operation, maintenance, and future enhancements, including guidance for program-personnel configuration (Task 1.8).

Task 4 – Transition Out

Preparations for Transition-Out should be started by the contractor in conjunction with the COR and technical/programmatic government staff early in the contract execution, developing a state of readiness for transition to both government staff and subsequent contractors. Materials should include links to all code repositories, accounts, rights, and necessary SOPs to continue execution of the functions.

The Contractor shall:

4.1 Maintain a Transition-out readiness posture where documentation is assessed at least monthly based on project delivery timeframes and provided to the COR and technical representatives. This should include (but is not limited

to) any documentation, system and email and other account access, code bases, processes, and other assets necessary to understand and operate the systems and related procedures. These assets and the ability to assign access should always be available to designated FTEs to ensure continuity of operations.

4.2 Facilitate the transition out of contracted activities and services to the Federal Government or, to a follow-on

Contractor by the end of the task order period of performance.

4.3 During the transition-out, ensure no degradation in support provided under the Task Order.

4.4 The incumbent Contractor shall submit to the COR, for approval, a detailed Transition-out Plan at least two (2) months prior to contract end. The plan shall identify tasks, roles, and responsibilities for contractor staff during the transition, and transition-out schedule and milestones to ensure an orderly and complete transition.

4.5 Lead Technical Exchange Meetings (TEMs) with the successor to impart knowledge transfer of all processes, projects, systems, applications, and databases, as well as sustainment activities.

4.6 Provide the government with the accurate and most current versions of all documentation developed under the

TO.

4.7 Provide the government a current inventory of all Government-owned assets used by the Contractor along with full support in the reconciliation of this inventory.

4.8 Provide the government with access to full documentation of and all custom code, user accounts, and configurations (not COTS source code), reports, process automations, scripts and configurations with applicable configuration management information.

4.9 Provide current status and reference to materials for governance, security and privacy or other approval aspects of each project or activity.

4.10 Provide the successor with the ability to “shadow” and participate in other knowledge transfer meetings and opportunities to facilitate the transfer of information, processes, and data needed to continue the services being performed by the Contractor

4.11 Perform all task order closeout activities and provide sustainment support to complete the transition.

SECTION 5 – GOVERNMENT FURNISHED PROPERTY

Personal Identity Verification (PIV) cards and laptops will be furnished by the government. CDC will provide access to the CDC-managed Azure environment for development, testing, and deployment, coordinated with OCIO and governed by the ATD.

SECTION 6 – PLACE OF PERFORMANCE AND CONTRACT SUPPORT

HOURS

SUBSECTION A – PLACE OF PERFORMANCE

Primary place of performance is remote at the Contractor's facility(ies) within the United States. The Contractor shall coordinate routinely with CDC personnel located in Atlanta, Georgia, and shall participate in virtual meetings as required. Any on-site activities at CDC facilities, if requested by the Government, shall be coordinated in advance by the COR and shall comply with CDC security and facility access requirements.

SUBSECTION B – CONTRACT SUPPORT HOURS

The Contractor shall provide contract support during CDC core business hours, Monday through Friday, 8:30 a.m.

to 5:00 p.m. Eastern Time (ET), excluding Federal holidays. Support outside of core business hours may be requested by the Government on an as-needed basis for planned releases or time-sensitive activities and shall be coordinated in advance with the COR.

SECTION 7 – TRAVEL

No travel, other than that necessary for employee onboarding, is anticipated for this contract. The Contractor shall perform work remotely and coordinate with CDC via virtual meetings. If the Government requests travel (e.g., for in-person meetings at CDC Atlanta), travel must be approved in advance by the COR and shall be reimbursed in accordance with applicable Federal Travel Regulation (FTR) requirements and the travel terms of the contract.

SECTION 8 – DELIVERABLES/REPORTING SCHEDULE

Dates are re-baselined to a nine-month PoP. Deliverables shall be submitted electronically unless otherwise directed by the COR. The Contractor shall address Government comments and resubmit as requested.

Task Deliverable Quantity/Format Due Date Deliver To

PM / Task 4

Project Plan + Deployment and

Hosting Plan (CDC/HHS-managed cloud)

1 / MS Word Within 10 calendar days after DOA

COR (copy

CO)

Task 1 UX Wireframes, User Flows, and

Landing Page/Navigation Redesign

1 set / PDF or web export

Within 21 calendar days after DOA

COR

Task 1

Technical Design Document (incl.

branching logic; low-code approach if retained)

1 / MS Word Within 30 calendar days after DOA

COR

Task 1 Working Prototype (Alpha)

Demonstration Build

1 / web application build

Within 45 calendar days after DOA

COR

Tasks 1–3 Beta Release

1 / deployable web application build

Within 90 calendar days after DOA

COR

Task 2 Customer centric design, intelligent form assistance, and usage metrics 1 / MS Word With Beta Release COR

Task 2 Frequently Asked Questions Data

Report

1 / MS Word or data export

With Beta; updated with

Final

COR

Task 1

Customer Satisfaction Survey

Instruments (site navigation + post-submission pop-up)

1 set / MS Word or web With Beta Release COR

Task 3 Phase 1 Upload Implementation and

Phase 2 Design Provisions 1 / MS Word With Beta Release COR

Task 4 Security and Privacy Documentation

Package Supporting ATD Issuance

1 package / MS

Word + artifacts

In advance of deployment to support ATD; draft with

Beta

COR

Task 4 Compliance Documentation Package

(Security/Privacy/Section 508)

1 package / MS

Word + artifacts With Beta Release COR

Task 4 Accessibility Conformance Report

(ACR/VPAT) and Remediation Plan

1 / ACR/VPAT

With Beta; updated with

Final

COR

Tasks 1–4

Testing and Final Release

(Production-Ready) and

Source/Build Artifacts

1 / final deployable build

By end of PoP (DOA + 150 days)

COR

Tasks 1–4

User Guides (Public, Healthcare

Provider, Technical/Administrator);

Operation and Management (O&M), Architecture Designs, Process

Workflows

3 / MS Word or

PDF

With Final Release COR

PM Monthly Status Report 1 per month / MS

Word or PDF

By the 10th calendar day of each month

COR

PM

Final Report / Project Closeout

Summary 1 / MS Word By end of PoP

COR (copy

CO)

SUBSECTION A – PERFORMANCE MATRIX

Performance Objective Standard Performance

Threshold (AQL)

Method of

Surveillance

PRS#1 Branching Logic Correctness

(Task 1.6); Report submission form correctly serves public vs. healthcare-provider paths and suppresses AE-related fields for provider vaccine-error-with-no-

AE reports.

100% correct field presentation/suppression across

Government-defined test scenarios for both submitter types.

≤ 1 non-critical defect per acceptance test cycle; no critical defects.

100% Inspection during Government acceptance testing.

PRS#2 Mobile/Desktop Responsiveness

(Task 1.3); Application functions correctly on mobile devices and modern desktop browsers, enabling reporting from any internet-connected device.

Correct rendering and functional completion of core reporting flows across Government-defined device/browser matrix.

No critical defects; ≤ 2 high-severity defects at final release with approved remediation plan.

100% Inspection at acceptance; Periodic

Inspection through

Beta.

PRS#3 Landing Page and Navigation

Redesign (Task 1.4); Redesigned landing page and navigation provide clear access to reporting tools, FAQs, and data downloads, including link to the submission form.

All required access paths present, functional, and validated in

Government review.

No critical defects; all required access paths functional at Final

Release.

100% Inspection at acceptance.

PRS#4 Application Performance (Task

1.10) — Measure-and-Report, Page load ≤

3 seconds; median end-to-end submission time ≤ 10 minutes; submission abandonment reduced ≥ 30% vs. kickoff baseline.

Contractor measures and reports against targets using approved methodology; targets are not pass/fail acceptance gates per Task 1.10.

Reports delivered;

measured values documented with methodology; deviations explained.

Periodic Inspection of measurement reports;

automated monitoring where implemented.

PRS#5 Data Completeness (Tasks 1.1, 1.6, 1.9); Required and critical VAERS data elements complete in submitted reports

(public and provider).

≥ 90% completeness for required/critical VAERS data elements, measured via periodic analysis of submitted reports.

≥ 85%. Periodic Inspection and Random

Sampling; analytics review by

Government.

PRS#6 VAERS-Compatible Data Capture and Transmission (Task 1.9); End-to-end capture and transmission of VAERS-compatible structured data to existing

VAERS systems and workflows, as directed by CDC.

Successful generation and transmission of VAERS-compatible structured data for all required fields in Government acceptance testing.

≤ 1 critical defect per acceptance test cycle.

100% Inspection during Government acceptance testing.

PRS#7 Customer Satisfaction Surveys

(Tasks 1.5, 1.7); Site-navigation survey and post-submission pop-up survey implemented and operational.

Both surveys deployed, capturing responses, and results reported to

Government at defined intervals.

Both surveys deployed and functional at Final

Release; response data delivered per approved schedule.

100% Inspection at acceptance; Periodic

Inspection of survey data delivery.

PRS#8 Program-Personnel Editability /

Low-Code UI (Task 1.8); Authorized

CDC program personnel can make defined content and interface updates with limited developer support; change and configuration process documented.

Government-defined update scenarios completed by program personnel without developer code changes;

configuration/change process documentation delivered and approved.

≤ 1 update scenario requiring developer intervention;

documentation approved by COR.

100% Inspection during Government acceptance testing.

PRS#9 Medical Record Upload

Capability (Tasks 2.1, 2.2, 2.5); Integrated upload tool for medical records and free-text box for additional information, with existing post-submission upload tool maintained.

Upload tool integrated in form, free-text box functional, existing post-submission tool preserved, and

PHI/PII handling compliant.

No critical defects; ≤ 2 high-severity defects at

Final Release with approved remediation plan.

100% Inspection at acceptance; security review by

Government.

PRS#10 Supplemental Document

Suggestion Tool (Task 2.3); Tool scans healthcare-provider submissions and suggests supplemental documents to upload.

Tool operational and providing suggestions across Government-defined provider test scenarios.

≥ 90% suggestion coverage across defined scenarios; no critical defects.

100% Inspection during Government acceptance testing.

PRS#11 Two-Phase Upload — Phase 1

Implementation and Phase 2 Design

Provisions (Task 2.4); Phase 1 restricts uploads to medical records and vaccine documents; design accommodates future

Phase 2 expansion.

Phase 1 upload restrictions enforced;

design documentation demonstrating

Phase 2 extensibility delivered.

Phase 1 restrictions correctly enforced with no critical defects;

extensibility documentation approved.

100% Inspection at acceptance; Periodic

Inspection of design documentation.

PRS#12 ATD Issuance Support (Task 3.3)

— Security and privacy documentation sufficient for CDC (in coordination with

OCIO) to issue ATD enabling local testing, updates, and deployment.

ATD issued by CDC based on

Contractor-provided documentation;

Government review comments addressed and identified weaknesses remediated.

ATD issued in advance of production deployment; no unresolved critical findings at issuance.

100% Inspection at

ATD gate; Periodic

Inspection of remediation.

PRS#13 PHI/PII Protection and Security

Safeguards (Tasks 3.1, 3.4);

HIPAA/Privacy Act protection for data collected, processed, transmitted, stored;

documented technical/administrative safeguards; vulnerability scanning eliminates known vulnerabilities before deployment.

Safeguards implemented and documented; vulnerability scanning performed during development and pre-deployment with no known vulnerabilities at deployment.

No known critical/high vulnerabilities at deployment; safeguards documented and approved.

100% Inspection at pre-deployment;

Periodic Inspection of scan results.

PRS#14 Section 508 Conformance (Task

3.5); Web application and all deliverables conform to Section 508 and HHS ICT accessibility standards; ACR/VPAT and remediation plan provided.

No critical/high-severity accessibility defects at Final Release; ACR/VPAT and remediation plan for any nonconformities delivered.

No critical defects; ≤ 3 high-severity defects open at Final Release with approved remediation plan.

Periodic Inspection

(accessibility testing);

100% Inspection at acceptance.

PRS#15 Compliance Documentation

Package (Task 3.6); Required security, privacy, and Section 508 documentation submitted; Government review comments addressed.

Complete package delivered per

Section 8; Government comments addressed within agreed timeframes.

Package accepted by

COR; no unresolved critical review comments at Final

Release.

100% Inspection at delivery.

PRS#16 User and Administrator

Documentation (Tasks 1.12, 3.8); User-facing documentation and administrator/technical guides delivered, including program-personnel configuration guidance for Task 1.8.

All user, technical/administrator, and configuration guides delivered, accepted by COR, and aligned with final application UX.

All required guides delivered and accepted by COR at Final

Release.

100% Inspection at delivery.

PRS#17 Program Management and

Reporting (Subsection C); PMP, monthly status reports, bi-weekly technical reviews, and Cost Management Plan delivered and current.

PMP delivered and maintained;

monthly status reports on schedule;

bi-weekly technical reviews conducted; Cost Management Plan maintained.

≥ 95% on-time delivery of PM deliverables; no missed bi-weekly reviews without prior

COR agreement.

Periodic Inspection;

COR review.

PRS#18 Transition-Out Readiness (Tasks

4.1–4.9); Ongoing transition-readiness posture maintained; documentation assessed at least monthly; Transition-out

Plan delivered ≥ 2 months prior to contract end; no degradation in support during transition.

Monthly transition-readiness assessment provided to COR;

Transition-out Plan delivered on schedule and approved; TEMs conducted; no support degradation.

Monthly assessments on time; Transition-out

Plan delivered ≥ 2 months prior to end and approved; zero critical support degradation events during transition.

Periodic Inspection

(monthly assessments); 100%

Inspection at

Transition-out Plan delivery and closeout.

SECTION 9 – REFERENCE MATERIALS

• Government-provided VAERS data element definitions, business rules, and integration requirements for public and healthcare-provider reporting (provided at kickoff).

• Applicable federal and HHS/CDC information security, privacy, and accessibility policies and standards, including HIPAA, the Privacy Act, Section 508, and FedRAMP requirements.

• CDC/OCIO ATD requirements and CDC-managed Azure environment security requirements (provided at kickoff).

SECTION 10 – MINIMUM VENDOR QUALIFICATIONS

There are no minimum vendor qualifications beyond those evaluated under the solicitation's evaluation factors are specified in this PWS.

SECTION 11 – ADDITIONAL REQUIREMENTS

Information Security and Privacy

The Contractor shall comply with all applicable CDC, HHS, and federal information security and privacy requirements, including protections for PII and PHI under the Privacy Act and HIPAA. The Contractor shall implement security and privacy-by-design practices, including secure handling of PHI/PII during collection, processing, transmission, and storage, and shall use the CDC Azure environment (FedRAMP authorized and approved for use by CDC) to integrate with existing VAERS infrastructure. The Contractor shall provide adequate security and privacy documentation sufficient for CDC, in coordination with OCIO, to issue an Authority to

Develop (ATD) to deploy and Authority to Operate (ATO) the application onCDC infrastructure and enable local testing, updates, and deployment, and shall support Government reviews by responding to findings and implementing approved remediation.

Information Security and Privacy Compliance

Standard-1: Procurements Requiring Information Security and/or Physical Access Security

1. Baseline Security Requirements

a. Applicability. The requirements herein apply whether the entire contract or modification (hereafter

"contract"), or portion thereof, includes either or all of the followings. No contractor will be permitted to access or operate CDC infrastructure or systems overseas unless prior approval is received from

CDC CISO.

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

(electronic) access to government information.

ii. 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 CDC 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.

b. Safeguarding Information and Information Systems. All government information and information systems must be protected in accordance with HHS/CDC policies and level of risk. At a minimum, the

Contractor (and/or any subcontractor) must:

i. Protect the:

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

ii. Categorize all information owned and/or collected/managed on behalf of CDC and information systems that store, process, and/or transmit HHS information 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. Based on information provided by the ISSO, CISO, CDC CPO, or other representative, the impact level for each Security Objective (Confidentiality, Integrity, and

Availability) and the Overall Impact Level, which is the highest watermark of the three factors of the information or information system are the following:

▪ Confidentiality: [ ] Low [ x ] Moderate [ ] High

▪ Integrity: [ ] Low [ x ] Moderate [ ] High

▪ Availability: [ ] Low [ x ] Moderate [ ] High

▪ Overall Impact Level: [ ] Low [ x ] Moderate [ ] High

iii. Based on the agreed-upon level of impact, implement the necessary safeguards to protect all information systems and information collected and/or managed on behalf of CDC regardless of location or purpose.

iv. Report any discovered or unanticipated threats or hazards by either the agency or contractor, or if existing safeguards have ceased to function immediately after discovery, within one (1) hour or less, to the government representative(s).

v. Adopt and implement all applicable policies, procedures, controls, and standards required by the

CDC 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 all applicable security and privacy policies by contacting the CO/COR or CDC security and/or privacy officials.

c. Privacy Act. Comply with the Privacy Act requirements (when applicable), and tailor FAR and

HHSAR clauses as needed.

d. Privacy Compliance. Comply with the E-Government Act of 2002, NIST SP 800-53, and applicable

CDC privacy policies, and complete all the requirements below:

i. Per the Office of Management and Budget (OMB) Circular A-130, Personally Identifiable

Information (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.

ii. To ensure that the public's personal information is protected in a manner commensurate with the privacy risks, CDC uses a privacy analysis process to assess the risks associated with CDC's collection and maintenance of PII and to ensure information is handled in accordance with applicable legal, regulatory, and policy requirements. PTAs analyze how information is handled in IT systems and electronic information collections and determines if the IT system or electronic information collection collects, disseminates, maintains, or disposes of PII. PIAs are used to assess the privacy risks of IT systems and electronic information collections that collect, disseminate, maintain, or dispose of PII about members of the public. PIAs also provide transparency into how CDC collects, disseminates, maintains, or disposes of the public's PII.

http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf

iii. The Contractor must support the agency with conducting a Privacy Threshold Analysis (PTA) for the information system and/or information handled under this contract to determine whether or not PII is collected, disseminated, maintained, or disposed as part of the contract. The PTA will determine if a full Privacy Impact Assessment (PIA) needs to be completed.

▪ If the results of the PTA show that a full PIA is needed, the Contractor must support the agency with completing a PIA for the system or information within 60 days after completion of the PTA and in accordance with CDC policy and OMB M-03-22, Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002.

▪ The Contractor must support the agency in reviewing the PIA at least every three years throughout the system development lifecycle (SDLC)/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.

e. Controlled Unclassified Information (CUI). Executive Order 13556 defines CUI 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. The requirements below apply only to nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components.

All sensitive information that has been identified as CUI by a regulation or statute, handled by this solicitation/contract, must be:

i. Marked appropriately;

ii. Disclosed to authorized personnel on a Need-To-Know basis;

iii. Protected in accordance with NIST SP 800-53, Security and Privacy Controls for 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

iv. Returned to HHS/CDC control, destroyed when no longer needed, or held until otherwise directed. Information and/or data must be disposed of in accordance with NIST SP 800-88, Guidelines for Media Sanitization.

f. 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) must protect all government information that is or may be sensitive by securing it with a solution that is validated with current FIPS 140 validation certificate from the NIST

CMVP.

g. Confidentiality and Nondisclosure of Information. Any information provided to the contractor

(and/or any subcontractor) by CDC or collected by the contractor on behalf of CDC must be used only for the purpose of carrying out the provisions of this contract and must 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 must ensure that all work performed by its employees and subcontractors must be under the supervision of the Contractor. Each Contractor employee or any of its subcontractors to whom any

CDC records may be made available or disclosed must 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 must be protected in accordance with HHS/CDC policies. Unauthorized disclosure of information will be subject to the HHS/CDC sanction policies and/or governed by the following laws and regulations:

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

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

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

h. Internet Protocol Version 6 (IPv6). All procurements using Internet Protocol must comply with

OMB Memorandum M-05-22, Transition Planning for Internet Protocol Version 6 (IPv6).

i. Information and Communications Technology (ICT). ICT products and services from prohibited entities/sources must not be used/acquired in compliance with Public Law 115-232, Section 889 Parts

A and B, FAR 4.21, FAR 52.204.23, FAR 52.204.24, and FAR 52.204.25. The contractor (and/or any subcontractor) must notify the government if they identify prohibited ICT products and/or services are used during the contract performance.

j. 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 must enable HTTP Strict Transport Security

(HSTS) to instruct compliant browsers to always assume HTTPS to reduce the number of insecure redirects and protect against attacks that attempt to downgrade connections to plain HTTP. For internal-facing websites, HTTPS is not required, but it is highly recommended. Consult HHS/CDC

Policy for Internet and Email Security for additional information.

k. Contract Documentation. The Contractor must use provided templates, policies, forms and other agency documents specify which documents/forms will be provided to contractor] to comply with contract deliverables as appropriate.

l. Standard for Encryption. The Contractor (and/or any subcontractor) must:

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

ii. 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 encryption solution that is validated with current FIPS 140 validation certificate from the NIST CMVP.

iii. Secure all devices (i.e.: desktops, laptops, mobile devices, etc.) that store and process government information and ensure devices meet and CDC Component-specific encryption standard requirements.