NBS 7 technical deployment phases

This page describes the three NBS 7 deployment phases and covers what each phase includes and when to deploy it. The first phase is the core deployment, which gives your jurisdiction NBS 6 feature parity on modern cloud infrastructure. Real-Time Reporting (RTR) and the Data Ingestion (DI) API follow as subsequent phases. Separating the phases reduces initial deployment risk and gives your team time to learn the system before taking on additional complexity.

Phase 1: NBS 7

The first phase is the base deployment. NBS 7 gives your jurisdiction NBS 6 feature parity on modern, cloud-based infrastructure, with foundational improvements such as real-time patient search. Additional modules and functional areas are modernized incrementally across releases.

When to deploy

Deploy Phase 1 first. All subsequent phases depend on it. Plan your RTR and DI API timelines before you begin so your team can sequence the phases without gaps.

NBS 7 core components are organized into three layers: networking, infrastructure, and application. For details on what each core component does and when you need it, see NBS 7 core components in the Component Reference.

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

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

Kubernetes cluster (EKS on AWS, AKS on Azure)
Traefik Ingress Controller (as of NBS 7.12; formerly NGINX)
AWS or Azure managed services
Terraform infrastructure automation modules
Load balancer

Application layer

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

Phase 2: Real-Time Reporting (RTR)

RTR is the second deployment phase. It introduces an event-driven reporting pipeline that runs alongside the legacy MasterETL batch process during the transition, with the goal of eventually decommissioning the batch process.

When to deploy

Deploy Phase 2 after Phase 1 is stable. RTR is part of the full deployment and should be planned from the start.

RTR adds the following components to your NBS 7 deployment. For details, see Add-on: Real-Time Reporting (RTR).

Phase 3: Data Ingestion (DI) API

The DI API is the third deployment phase. It provides a built-in data transit layer and a REST API interface for writing data to NBS. DI API serves as a secure intermediary between your middleware and the database.

When to deploy

Jurisdictions that need an API-based ingestion path due to security constraints should plan Phase 3 in parallel with or immediately after Phase 2.

The DI API supports two integration methods. The right choice depends on your jurisdiction’s security policies and how your middleware is deployed.

Integration method	Rationale
Direct SQL Write	Standard for jurisdictions where middleware such as Rhapsody can access the database directly.
DI API	Used when security policies prohibit direct database access from third-party tools or when middleware cannot be co-located with NBS.

The DI API is not a replacement for middleware. An integration engine such as Rhapsody is required to preprocess and format data before it is sent to the DI API.

For more information, see Data Ingestion (DI) API in the Component Reference.