Managed Cloud Hosting for CDC-supported Public Health Applications

Active

Contract Opportunity

Request for Information

Managed Cloud Hosting for CDC-supported Public Health Applications

Introduction

This is a Request for Information (RFI) issued only for the purpose of conducting market research. Accordingly, this RFI constitutes neither a Request for Proposal nor a guarantee that one will be issued by the Government in the future; furthermore, it does not commit the Government to contract for any services described herein. Do not submit a Proposal. This notice is not to be construed as a commitment on the part of the Government to award a contract, nor does the Government intend to pay for any information submitted in response to this request. The Government does not reimburse respondents for any costs associated with submission of the information being requested or reimburse expenses incurred for responses to this RFI. The information provided may be used by CDC in developing its acquisition strategy. Any information submitted by respondents to this RFI is strictly voluntary; however, any information received shall become the property of the Government and will not be returned to the respondent. Interested parties are responsible for adequately marking proprietary, restricted or competition sensitive information contained in their response. This is an RFI and does not obligate the Government in any way, nor does it commit the Government to any specific course of action.

Please provide responses to the questions below and any additional comments or information to clearly identify the capabilities of your suggested solution(s). The Government is seeking as much information as possible and a complete response to this RFI during this market research activity.

Background

The mission of the Office of Public Health Data, Surveillance, and Technology (OPHDST) at the Centers for Disease Control and Prevention (CDC) in Atlanta, Georgia is to optimize timely access, exchange, and integration of public health data while driving efficiency and consolidation of data and technology systems supported by CDC across all levels of public health and advancing open data and dissemination to inform decision making and action. In summary, the Office ensures the right data, at the right time, is in the right hands so public health authorities (PHAs) can make informed decisions.

Case surveillance is foundational to public health practice. It helps public health officials understand the burden of health conditions of public health importance, monitor the spread of communicable diseases, and determine appropriate actions to reduce disease transmission. Case surveillance starts at state, tribal, local, and territorial public health departments (STLTs). STLTs work with healthcare facilities to get the information they need to monitor, control, and prevent reportable diseases and conditions in their communities.

Healthcare facilities are legally mandated to report a set of conditions to their STLT public health department(s) – this is called “case reporting.” STLTs also notify CDC about certain conditions so that the CDC can perform national case data tracking – this is called “case notification.” Through the National Notifiable Diseases Surveillance System (NNDSS), CDC monitors about 120 notifiable diseases and receives deidentified data on additional conditions at jurisdiction’s discretion.

CDC develops and supports applications and tools tailored to specific public health functions for STLTs, including tools for surveillance, electronic lab report (ELR) processing, electroinc case report (eCR) processing and case management, each requiring reliable, standards-based hosting infrastructure. These tools are either used by STLTs as hosted applications or they may be deployed by the STLTs.

STLTs use NNDSS-compatible integrated disease surveillance systems (IDSS) to manage cases for multiple diseases and conditions and transfer epidemiologic, laboratory, and clinical data efficiently and securely over the Internet to CDC. STLTs may choose which IDSS they prefer to use. Operating these systems can be complex, as STLTs must establish and maintain:

• interfaces for receiving, validating, and processing electronic lab record (ELR) and electronic case records (eCR) sent via standard protocols by laboratories and healthcare;


• appropriate settings for users, program areas, jurisdictions, conditions (e.g. LOINC and SNOMED codes), workflow rules, and configuration necessary to create conforming case data;


• mechanisms for reporting case data to CDC, including sending NNDSS-compliant notifications to the CDC;


• necessary security and monitoring tools to ensure that data is flowing and cases are being updates appropriately, such as server certificates and logs.

One such system is the National Electronic Disease Surveillance System (NEDSS) Base System (NBS), which serves as a reference implementation for jurisdictions. NBS is open-source, and has historically been made available through NBS Central as a free package for STLTs to download, install, and manage on the Windows server environment of their choice – for example, an on-premise data center, via an outsourced IT services partner, or in virtual machines on a STLT-contracted cloud host. However, CDC also supports other tools such as SimpleReport and DIBBs, which can be hosted and maintained alongside or independent of surveillance systems.

An IDSS is just one component in a health department’s disease surveillance tool suite, and the IDSS typically relies on additional tools and applications to collect, ingest, process, analyze, output, and develop reports against the surveillance data. As such, STLTs will typically host and maintain freely available CDC-developed software alongside NBS, such as DIBBs, or licensed third party products, such as Rhapsody/Mirth, SAS/R, and Power BI/Tableau. Further, they rely on CDC-hosted tools such as SimpleReport for the collection and transmission of laboratory results data.

To reduce hosting burden for STLTs and CDC, the CDC Office of the Chief Information Officer (OCIO) stood up a CDC Enterprise cloud leveraging Microsoft Azure. However, this cloud has some limitations and not all STLTs may be able to avail of CDC managed cloud services. Some of these limitations include: inability for a STLT to sign the Terms of Access; inability for STLTs to directly log in to and manage the virtual server resources; and, reliance on CDC staffing and funding to make changes and upgrades to the cloud environment.

As such, CDC is in the planning stages of identifying alternative cloud hosting options for CDC-developed tools and applications, including tools for data collection, data processing and STLT disease surveillance applications (and their related systems) where CDC could implement a cost sharing model which enables both STLTs and CDC to contribute funds to the overall hosting costs. CDC is seeking input from third parties interested in managing cloud infrastructure on behalf of public health, across a range of applications (e.g., surveillance systems, lab processing tools, reporting systems, and registries) and to determine the impact (i.e., cost, operational, schedule, reliability, performance) of 1) migrating existing STLT disease surveillance systems from their current hosting environment to one or more central cloud service providers (CSPs), 2) migrating existing CDC hosted applications from their current hosting environment to one or more central cloud service providers (CSPs), and 3) establish new implementations of CDC-developed data processing applications in one or more central cloud service providers (CSPs).

Note: NBS and DIBBs can currently be deployed in both AWS and Azure clouds, with additional partial support for Google Cloud Platform (GCP). An open-source scripted deployment package is available on Github that can be freely used to install, maintain, and monitor NBS in any Azure or AWS account. While most services are designed to be cloud-agnostic, one service - SimpleReport - can currently only be deployed as an App Service with supporting Azure Functions in Microsoft’s Azure cloud.

• Attachment A provides a sample listing of software used by NBS in the cloud


• Attachment B provides an estimate of a representative STLT environment


• Attachment C provides a generalized list of required SimpleReport and DIBBs tools and services

Response(s)

The purpose of this RFI is to gather additional information to help CDC determine the most suitable strategy to extend and evolve cloud hosting options for STLTs. Interested parties are encouraged to provide details relative to the following areas:

1. Current capabilities. What capabilities (commercial, non-profit, public/private partnership, and/or consortia) can you provide for managing public health use-cases in the cloud. For a given managed service, for example, hosting an immunization registry or managing the exchange of vital records, please provide:
   
   
   
   
   1. 
      
      
      
      1. representative compute architecture (e.g. types of servers and networking)
      
      
      2. underlying or outsourced cloud service provider such as AWS, Azure, Google Cloud Platform, Rackspace, etc., contracted 3rd party hosting, and/or if compute is available on-premise;
      
      
      3. typical data volumes, expressed in units such as # of database records, # of transactions per day, megabytes transferred per day, # of concurrent of users, volume of compute (RAM, CPUs, storage), etc.;
      
      
      4. illustrative staffing / skillsets necessary to maintain the service;
      
      
      5. indicative service level agreements (SLAs), if any, such as operational windows, scheduled downtimes, incident response times, geo-redundancy, or disaster recovery points.
      
      
      
      
   
   
   
   


2. Security. How would the confidentiality, integrity, and availability of protected health information (PHI) and personally identifiable information (PII) within hosted systems would be maintained in the cloud? What agreements would STLTs be required to sign in order to leverage hosting? Would STLTs have full and direct access to cloud resources and databases?


3. Migration. How could a replacement of a STLT’s existing systems hosting be achieved? In other words, what would be the anticipated cost, schedule, operational and sustainment impacts of migrating a representative STLT’s IDSS from its existing hosting to the new CSP? How would this transition be accomplished? Can you guarantee that a STLT can always access their data and that it is wholly owned by them (i.e., data will not be held “hostage”, nor will you comply with any demands to hand over STLT data to another party)?


4. Service optimization. What value and benefits could be achieved by expanding CDC’s existing hosting option to include additional CSPs? How would these values and benefits outweigh potential duplicative up-front costs, as well as additional ongoing sustainment costs?


5. Funding and cost sharing. CDC grants have historically not been funded to fully cover STLT-operated software or hosting, and CDC grants cannot be “charged back”, both of which are a challenge when finding ways to provide funding assistance. What mechanisms exist (or might be proposed) for CDC and/or STLTs to fund such hosting? What other sources of funding are anticipated? Can funds from STLTs, CDC, and/or other funding sources be combined to support hosting costs for a single STLT? How would you propose arranging a cost-sharing model for hosting services?


6. Additional services. Could you provide any additional proposed services beyond managed hosting that would benefit STLTs, such as ELR or eCR pre-processing, MPI services, or assistance in moving to from a previous IDSS to a new IDSS system?


7. Environment support. Can multiple isolated environments be created and managed per STLT to support a typical Validation -> Staging -> Production deployment architecture? Are each of the environments able to be rolled back in the event of a failed or malfunctioning deployment? What downtime is expected during environment migrations?


8. Risks and barriers. What potential risks, barriers, or other challenges would prevent a STLT from using this shared hosting model? Likewise, what risks, barriers, or challenges would prevent you from allowing a STLT to avail themselves of hosting services? Under what conditions would a STLT’s hosting services be terminated? What limitations (such as data volume or bandwidth requirements) would disqualify a STLT from hosting?

Responses for the above should include an estimated migration timeframe and cost, as well as what additional capabilities any proposed alternative or replacement CSP would offer that may not be already available from STLT’s existing hosting providers.

Please submit the requested information by 4:00 PM EST on November 30, 2025 via email to jpowell5@cdc.gov. CDC reserves the right to respond to any, all, or select respondents. CDC appreciates your time and anticipated response.

Attachment A – sample NBS managed software list

Software Version

Kubernetes (K8s) 1.25+

Cert Manager 1.13

Elasticsearch 7.17

Apache NiFi 1.19

NGINX Ingress 3.0.2

Prometheus 2.44

Grafana 9.5.x

FluentBit 1.9.x

NBS Core Server NBS 6.0.16+ (Wildfly 10 J2EE Server)

SQL Server 2017+

Kafka 2.8.1

Keycloak 22.0.5+

sFTP Server Any

Attachment B - estimate of representative STLT current IDSS environment

Resource Size

Compute Nodes 5-7 x 4vCPU/32Gb/30Gb disk

DB Server 16 vCPU/64Gb/1Tb DB

Persistent Store 2 Tb

# of ELRs per day 3,000 (10-200kb)

# of ECRs per day 300 (10kb to 30Mb, with average size of 1-2Mb)

# of Unique Person Records 2,000,000

Note: most STLTs will operate 2-3 separate environments e.g. DEV/TEST/PROD

Attachment C - generalized list of required SimpleReport and DIBBs tools and services

SimpleReport

Container runtime for simple service with demand-driven scaling. (Azure App Service, AWS Elastic Container Service, Google Cloud Run)

Serverless function app/lambda support (Azure Functions, AWS Lambda, etc.)

Load balancer/gateway with WAF support

Secrets/certificate management tool (Azure Key Vault, AWS Secrets Manager, etc.)

PostgreSQL 14.x

Okta Identity Engine

Twilio SendGrid integration (email support)

Cloud-based application insights and monitoring (e.g. Azure Application Insights)

PagerDuty or similar alerting/on-call integration (ideal, but not required)

Cloud-based message queueing (Azure Storage queue, etc.)

Cloud-based static HTTP hosting (Azure Storage Account, etc.)

eCR Viewer

Containerized

Container runtime for complex service stack.

* Azure Container Apps (managed K8s)

* AWS Elastic Container Service

* Generic K8s/Helm (requires additional development support - not officially supported)

Virtual Machine

Hypervisor support for VMs derived from .raw image files (custom).

* Cloud-based (GCP Compute Engine officially supported)

* On-premise (Proxmox officially supported; other hypervisors available)

Supporting Infrastructure

PostgreSQL 13.x+ OR Microsoft SQL 2022 or later (cloud or on-premise)

Microsoft Entra/Azure AD OR Keycloak 26.1+

Cloud-based container registry (Azure Container Registry, AWS ECR)

Load balancer/gateway with WAF support

Secrets/certificate management tool (Azure Key Vault, AWS Secrets Manager, etc.)

Cloud-based blob storage

Query Connector

Container runtime for simple service with demand-driven scaling. (Azure App Service, AWS Elastic Container Service, Google Cloud Run)

Microsoft Entra/Azure AD OR Keycloak 26.1+

PostgreSQL 14.x+

Load balancer/gateway with WAF support

Secrets/certificate management tool (Azure Key Vault, AWS Secrets Manager, etc.)

eCR Refiner

Container runtime for simple service with demand-driven scaling. (Azure App Service, AWS Elastic Container Service, Google Cloud Run)

Load balancer/gateway with WAF support

Secrets/certificate management tool (Azure Key Vault, AWS Secrets Manager, etc.)

Keycloak 26.1+

Additional tools as development proceeds.

Record Linker

Container runtime for simple service with demand-driven scaling. (Azure App Service, AWS Elastic Container Service, Google Cloud Run)

Load balancer/gateway with WAF support

Secrets/certificate management tool (Azure Key Vault, AWS Secrets Manager, etc.)

Additional tools as development proceeds

Glossary

CDC

Centers for Disease Control and Prevention. The federal agency responsible for disease and condition tracking, located within the Health and Human Services (HHS) department of the US Government.

DIBBs

Data Integration Building Blocks. A CDC-created set of tools focused on enhancing public health data integration and analytics capabilities. DIBBs runs as a standalone service with API endpoints to access its functionalities.

eCR

Electronic Case Report

ELR

Electronic Lab Report

IDSS

Integrated Disease Surveillance System. The software application which is used to track diseases and conditions for a public health authority (PHA).

MPI

Master Patient Index. A centralized database containing all patients in a registry, typically used for matching, linking, and deduplication processes for patient records.

NBS

NEDSS Base System. An open-source integrated disease surveillance system build and managed by CDC. It was originally conceived as the “base” system to implement the standardized disease and condition tracking framework outlined in NEDSS.

NEDSS

National Electronic Disease Surveillance System. The standardized framework built by CDC to improve the efficiency and effectiveness of national public health surveillance.

NNDSS

National Notifiable Diseases Surveillance System. The CDC-owned and operated system which received deidentified disease surveillance data in order to perform national reporting.

PHA

Public Health Authority. The entity within a jurisdiction (STLT) which has the responsibility to track and report on diseases and conditions within its area of responsibility.

STLT

State, Tribe, Local, or Territory. Used to reference any of the jurisdictional entities which perform disease surveillance or other public health activities.

Attachments/Links