Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 11 additions & 15 deletions docs/1_introduction/deployment_decision_guide/0_assess_readiness.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,28 +7,28 @@ nav_order: 1
description: Covers the technical prerequisites an STLT must meet before beginning NBS 7 migration, including cloud, staffing, and network requirements.
---

## Assess your readiness for NBS 7
# Assess your readiness for NBS 7
{: .no_toc }

This section helps you assess whether NBS 7 is a viable option for your jurisdiction before you commit to a migration. Some prerequisites in this section are also covered in the **NBS 7 Migration Info Sheet**. If your jurisdiction has already begun the migration process, use that document alongside this one.

{: .note }
**Health department leaders:** For key considerations on migration planning, staffing, and budget, see [Leadership considerations](leadership_considerations.html).

If you work through this section and find that your jurisdiction does not meet one or more prerequisites, you might still be able to move forward. You can address some gaps with planning and lead time, but other gaps might indicate that NBS 7 is not the right fit for your jurisdiction right now.
## On this page
{: .no_toc .text-delta }

1. TOC
{:toc}

---
If you work through this section and find that your jurisdiction does not meet one or more prerequisites, you might still be able to move forward. You can address some gaps with planning and lead time, but other gaps might indicate that NBS 7 is not the right fit for your jurisdiction right now.

For more information on migration planning, staffing, and budget, see [Operational considerations](leadership_considerations.html).
{: .note }

## State IT security approval

Has your jurisdiction obtained state IT security approval for cloud hosting and the software technologies that NBS 7 requires, including Kubernetes, Terraform, and Docker?

- **Yes, or approval is not required** — Continue with the rest of this section.
- **No, or unknown** — Begin the approval process now. Approval timelines vary and can significantly affect your migration schedule. Work with your state IT office while you continue planning.

- **No, or unknown** — Approval timelines vary and can significantly affect your migration schedule. We recommend working with your state IT office while you continue to plan.

## Cloud infrastructure

Expand All @@ -39,7 +39,6 @@ You need an active account with a supported cloud provider:
- **Amazon Web Services (AWS)** — The primary supported option. NBS 7 has been fully tested on AWS.
- **Microsoft Azure** — Supported via Terraform. Use this option if your jurisdiction has an existing Azure commitment or a compliance requirement that mandates Azure.


## Technical staff capacity

NBS 7 uses Kubernetes, a container orchestration platform. To deploy and maintain NBS 7, you need staff who can:
Expand All @@ -51,9 +50,8 @@ NBS 7 uses Kubernetes, a container orchestration platform. To deploy and maintai

If your IT team does not have these skills, you have two options:

- **Build capacity** — Train existing staff or hire staff with these skills before you begin deployment.
- **Use a vendor** — Contract with a vendor to deploy or manage your NBS 7 infrastructure. See [Vendor-managed deployment](1_choose_configuration/3_vendor_managed_deployment.html) for guidance on what to look for in a vendor.

- **Building capacity** — Train existing staff or hire staff with these skills before you begin deployment.
- **Working with a vendor** — Contract with a vendor to deploy or manage your NBS 7 infrastructure. See [Vendor-managed deployment](1_choose_configuration/3_vendor_managed_deployment.html) for guidance on what to look for in a vendor.

## Network readiness

Expand All @@ -67,7 +65,6 @@ Before deployment, your network must meet the following requirements:

Your specific network configuration will depend on your cloud provider and the existing infrastructure for your jurisdiction.


## NBS 6 status

During migration, NBS 7 components gradually replace NBS 6 functionality while NBS 6 continues to run. This means:
Expand All @@ -77,10 +74,9 @@ During migration, NBS 7 components gradually replace NBS 6 functionality while N
- You need to know your current NBS 6 hosting setup before you begin — specifically, whether it is hosted on-premises or in the cloud, and if in the cloud, which provider.
- **You must be running NBS 6.0.16.1 or higher** before you can install any version of NBS 7. Verify your current NBS 6 version before you begin planning your migration timeline.


## CDC coordination

Contact your CDC NBS point of contact before you begin deployment. CDC provides deployment support at no cost and can help you:
Reach out to your CDC NBS point of contact before you begin deployment. CDC provides deployment support at no cost and can help you:

- Validate your technical readiness
- Identify the right configuration for your jurisdiction
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,15 @@ has_children: true
description: Guides STLT administrators through the NBS 7 configuration options and helps identify the right starting configuration for their jurisdiction.
---

## Choose your NBS 7 configuration
# Choose your NBS 7 configuration
{: .no_toc }

NBS 7 is modular. Rather than a single fixed system, it is a set of components that you assemble based on the size, technical capacity, and public health needs of your jurisdiction. The following sections help you understand your options and identify the right starting configuration for your jurisdiction.
<!--
## On this page
{: .no_toc .text-delta }

1. TOC
{:toc}
-->

You can deploy the base NBS 7 product on its own, or with optional add-ons based on the size, technical capacity, and public health needs of your jurisdication. The following pages help you understand your options and identify the right starting point for your needs.
Original file line number Diff line number Diff line change
@@ -1,39 +1,42 @@
---
title: Configuration tiers
title: NBS 7 and available add-ons
layout: page
parent: Choose your configuration
grand_parent: NBS 7 Deployment Decision Guide
nav_order: 1
description: Describes the four NBS 7 configuration tiers — NBS Core, Core + RTR, Core + DI API, and NBS Complete — and when each is appropriate.
description: Describes NBS 7 and its two optional add-ons — Real-Time Reporting (RTR) and the Data Ingestion (DI) API — and when each is appropriate.
---

## NBS 7 configuration tiers
# NBS 7 and available add-ons
{: .no_toc }

This section describes the four ways to deploy NBS 7. You do not have to deploy everything at once. Most jurisdictions will start with NBS Core, then add RTR or the DI API as their team builds confidence with the platform. Starting smaller reduces deployment risk and gives your team time to learn the system before taking on additional complexity.
NBS 7 is the base product. Two optional add-ons are available: Real-Time Reporting (RTR) and the Data Ingestion (DI) API. You do not have to deploy add-ons at the outset. Most jurisdictions deploy NBS 7 first, then evaluate add-ons as their team builds confidence with the platform. Starting without add-ons reduces deployment risk and gives your team time to learn the system before taking on additional complexity.

## On this page
{: .no_toc .text-delta }

1. TOC
{:toc}

After you review the configuration tiers, use the [decision tree](2_decision_tree.html) to identify your recommended starting configuration. If your jurisdiction plans to use a vendor, see the [Vendor-managed deployment](3_vendor_managed_deployment.html) page.
After you review the available options, use the [decision tree](2_decision_tree.html) to identify your recommended starting configuration. If your jurisdiction plans to use a vendor, see the [Vendor-managed deployment](3_vendor_managed_deployment.html) page.

---

### NBS Core
## NBS 7

The minimum viable deployment. NBS Core gives your jurisdiction NBS 6 feature parity on modern, cloud-based infrastructure, plus foundational NBS 7 improvements such as real-time patient search.
The base deployment. NBS 7 gives your jurisdiction NBS 6 feature parity on modern, cloud-based infrastructure, plus foundational improvements such as real-time patient search.

NBS Core components are organized into three layers. For details on what each component does and when you need it, see [NBS Core components](../3_component_reference/1_nbs_core_components.html).
NBS 7 core components are organized into three layers. For details on what each component does and when you need it, see [NBS 7 core components](../3_component_reference/1_nbs_core_components.html).

**Networking layer**
### Networking layer

The networking layer manages traffic routing and secure communication between your NBS 6 and NBS 7 environments.

- DNS infrastructure (Route 53 or equivalent)
- Virtual Private Cloud (VPC) and routing groups
- VPN connectivity between NBS 6 and NBS 7 instances

**Infrastructure layer**
### Infrastructure layer

The infrastructure layer provides the container orchestration platform and cloud services that host and run NBS 7 components.

Expand All @@ -43,7 +46,7 @@ The infrastructure layer provides the container orchestration platform and cloud
- Terraform infrastructure automation modules
- Load balancer

**Application layer**
### Application layer

The application layer contains the NBS 7 services and legacy NBS 6 components that users and administrators directly interact with.

Expand All @@ -65,13 +68,13 @@ The application layer contains the NBS 7 services and legacy NBS 6 components th

---

### NBS Core + Real-Time Reporting (RTR)
## Add-on: Real-Time Reporting (RTR)

Core plus modern analytics. This configuration adds the Real-Time Reporting (RTR) pipeline, which we recommend using alongside the legacy MasterETL batch process during transition, with the goal of eventually replacing it.
RTR is an optional add-on that replaces the legacy MasterETL batch process with an event-driven reporting pipeline. We recommend running RTR alongside MasterETL during transition, with the goal of eventually replacing it.

**With RTR, data is available within 5 minutes to 1 hour instead of 24 hours.**

RTR adds the following components. For details, see [Add-on: Real-Time Reporting (RTR)](../3_component_reference/2_rtr.html).
RTR adds the following components to your NBS 7 deployment. For details, see [Add-on: Real-Time Reporting (RTR)](../3_component_reference/2_rtr.html).

- [Debezium](../3_component_reference/2_rtr.html#debezium)
- [Kafka and Kafka Connect](../3_component_reference/2_rtr.html#kafka-and-kafka-connect)
Expand All @@ -85,25 +88,13 @@ RTR adds the following components. For details, see [Add-on: Real-Time Reporting

---

### NBS Core + Data Ingestion (DI) API
## Add-on: Data Ingestion (DI) API

Core plus a built-in data transit layer. This configuration adds the Data Ingestion (DI) API, which accepts incoming public health data in multiple formats and routes it into NBS without requiring third-party middleware.
The DI API is an optional add-on that provides a built-in data transit layer. It accepts incoming public health data in multiple formats and routes it into NBS without requiring third-party middleware.

For details, see [Add-on: Data Ingestion (DI) API](../3_component_reference/3_di_api.html).

{: .note-title }
> Best for
>
> Jurisdictions that do not currently use Rhapsody or Mirth Connect for data ingestion, and want a built-in path for getting data into NBS 7.

---

### NBS Complete

The full NBS 7 deployment. NBS Complete includes NBS Core, RTR, and the DI API.

{: .note-title }
> Best for
>
> Jurisdictions with larger IT teams, high case volumes, and advanced reporting or analytics needs.

Original file line number Diff line number Diff line change
Expand Up @@ -7,82 +7,83 @@ nav_order: 2
description: A step-by-step decision tree that guides jurisdictions to a recommended NBS 7 starting configuration based on hosting model, capacity, and case volume.
---

## NBS 7 configuration decision tree
# NBS 7 configuration decision tree
{: .no_toc }

Use the decision tree to identify your recommended starting configuration. Answer each question in order, then validate your recommendation with the CDC NBS team before you begin deployment.

## On this page
{: .no_toc .text-delta }

1. TOC
{:toc}


{: .important }
The decision tree identifies a recommended starting point, not a final answer. CDC provides free pre-deployment consultation to help jurisdictions validate their configuration choice. Do not begin deployment without first connecting with the CDC NBS team at [nbs@cdc.gov](mailto:nbs@cdc.gov).

The decision tree identifies a recommended starting point, not a final answer. CDC provides free pre-deployment consultation to help jurisdictions validate their configuration choice. Connect with the CDC NBS team at [nbs@cdc.gov](mailto:nbs@cdc.gov) before you begin deployment.

### Step 1: Hosting model
## Step 1: Hosting model

Is your jurisdiction planning to self-host and self-maintain NBS 7, or will you use a vendor to host or maintain it?

- **Self-hosted, self-maintained** Go to [Step 2](#step-2-state-it-security-approval).
- **Vendor-hosted or vendor-maintained** Go to [Vendor-managed deployment](3_vendor_managed_deployment.html).
- **Self-hosted, self-maintained** Go to [Step 2](#step-2-state-it-security-approval).
- **Vendor-hosted or vendor-maintained** Go to [Vendor-managed deployment](3_vendor_managed_deployment.html).

### Step 2: State IT security approval
## Step 2: State IT security approval

Has your jurisdiction obtained state IT security approval for cloud hosting and the required software technologies (Kubernetes, Terraform, Docker)?

- **Yes, or approval is not required** Go to [Step 3](#step-3-internal-technical-capacity).
- **No, or unknown** Begin the approval process now, then continue planning. Approval is required before deployment. Go to [Step 3](#step-3-internal-technical-capacity).
- **Yes, or approval is not required** Go to [Step 3](#step-3-internal-technical-capacity).
- **No, or unknown** Begin the approval process now, then continue planning. Approval is required before deployment. Go to [Step 3](#step-3-internal-technical-capacity).

### Step 3: Internal technical capacity
## Step 3: Internal technical capacity

Does your jurisdiction have IT staff with skills in Kubernetes, Terraform, and cloud infrastructure management, roughly half or more of the required skill set?

- **Yes** Go to [Step 4](#step-4-current-nbs-6-hosting).
- **No** Go to [Step 3a](#step-3a-external-assistance).
- **Yes** Go to [Step 4](#step-4-current-nbs-6-hosting).
- **No** Go to [Step 3a](#step-3a-external-assistance).

### Step 3a: External assistance
## Step 3a: External assistance

Will your jurisdiction obtain external assistance from a contractor, vendor, or consultant for deployment and ongoing maintenance?

- **Yes** Go to [Step 4](#step-4-current-nbs-6-hosting). Note that your vendor or contractor must be capable of Kubernetes-based deployments on AWS or Azure. See [Vendor-managed deployment](3_vendor_managed_deployment.html) for what to look for.
- **No** **Stop.** Build internal capacity or identify a vendor before proceeding. Contact [nbs@cdc.gov](mailto:nbs@cdc.gov) for support resources.
- **Yes** Go to [Step 4](#step-4-current-nbs-6-hosting). Note that your vendor or contractor must be capable of Kubernetes-based deployments on AWS or Azure. See [Vendor-managed deployment](3_vendor_managed_deployment.html) for what to look for.
- **No** **Stop.** Build internal capacity or identify a vendor before proceeding. Contact [nbs@cdc.gov](mailto:nbs@cdc.gov) for support resources.

### Step 4: Current NBS 6 hosting
## Step 4: Current NBS 6 hosting

Where does your NBS 6 currently run?

- **Already on AWS** Lowest migration complexity. Go to [Step 5](#step-5-case-volume).
- **Already on Azure** Low migration complexity; you will follow the Azure-specific deployment path. Go to [Step 5](#step-5-case-volume).
- **On-premises** Your migration includes a cloud migration as well as an NBS 7 deployment. Plan for additional time and resources. Go to [Step 5](#step-5-case-volume).
- **Already on AWS** Lowest migration complexity. Go to [Step 5](#step-5-case-volume).
- **Already on Azure** Low migration complexity; you will follow the Azure-specific deployment path. Go to [Step 5](#step-5-case-volume).
- **On-premises** Your migration includes a cloud migration as well as an NBS 7 deployment. Plan for additional time and resources. Go to [Step 5](#step-5-case-volume).

### Step 5: Case volume
## Step 5: Case volume

What is the approximate annual reportable disease case volume in your jurisdiction?

- **Lower volume** (fewer than approximately 50,000 cases per year) Go to [Step 6](#step-6-data-intake-needs-lower-volume-jurisdictions).
- **Higher volume** (50,000+ cases per year), or significant growth expected Go to [Step 7](#step-7-reporting-needs-higher-volume-jurisdictions).
- **Lower volume** (fewer than approximately 50,000 cases per year) Go to [Step 6](#step-6-data-intake-needs-lower-volume-jurisdictions).
- **Higher volume** (50,000+ cases per year), or significant growth expected Go to [Step 7](#step-7-reporting-needs-higher-volume-jurisdictions).

{: .note }
The 50,000 case threshold is a planning guideline, not a hard rule. Validate your volume assessment with CDC before making a final configuration decision.

### Step 6: Data intake needs (lower-volume jurisdictions)
## Step 6: Data intake needs (lower-volume jurisdictions)

Does your jurisdiction currently receive high volumes of electronic lab reports (ELRs) or electronic case reports (eCRs)?

- **No** Recommended configuration: **NBS Core**. Validate with CDC before deploying.
- **Yes** Recommended configuration: **NBS Core + DI API**. Validate with CDC before deploying.
- **No** Recommended starting point: **NBS 7**. Validate with CDC before deploying.
- **Yes** Recommended starting point: **NBS 7 + DI API add-on**. Validate with CDC before deploying.

### Step 7: Reporting needs (higher-volume jurisdictions)
## Step 7: Reporting needs (higher-volume jurisdictions)

Does your jurisdiction need near-real-time reporting data available within minutes to hours, rather than 24 hours?
Does your jurisdiction need near-real-time reporting data available within minutes to hours, rather than 24 hours?

- **No** Contact [nbs@cdc.gov](mailto:nbs@cdc.gov) to discuss your specific needs. **NBS Core or NBS Core + DI API** may be appropriate starting points.
- **Yes** Go to [Step 8](#step-8-data-intake-needs-higher-volume-jurisdictions).
- **No** Contact [nbs@cdc.gov](mailto:nbs@cdc.gov) to discuss your specific needs. **NBS 7** or **NBS 7 + DI API add-on** might be appropriate starting points.
- **Yes** Go to [Step 8](#step-8-data-intake-needs-higher-volume-jurisdictions).

### Step 8: Data intake needs (higher-volume jurisdictions)
## Step 8: Data intake needs (higher-volume jurisdictions)

Does your jurisdiction currently receive high volumes of ELRs or eCRs?

- **No** Recommended configuration: **NBS Core + RTR**. Validate with CDC before deploying.
- **Yes** Recommended configuration: **NBS Complete**. Validate with CDC before deploying.
- **No** Recommended starting point: **NBS 7 + RTR add-on**. Validate with CDC before deploying.
- **Yes** Recommended starting point: **NBS 7 + RTR + DI API add-ons**. Validate with CDC before deploying.
Loading