RTR works alongside the legacy MasterETL batch process during transition, with the goal of eventually replacing it. The following components are added to your NBS Core deployment when you choose NBS Core + RTR or NBS Complete.
The primary benefit of RTR is speed. Data that previously took up to 24 hours to appear in reports is available within 5 minutes to 1 hour. For jurisdictions managing active outbreaks or time-sensitive disease investigations, this can meaningfully affect response time. But RTR adds infrastructure complexity and requires additional cloud resources, which will impact your operating costs.
An open-source Change Data Capture (CDC) platform.
| Attribute | Description |
|---|---|
| What it does in NBS 7 | Monitors the NBS database for changes in real time and streams those changes to Kafka as they occur. Debezium is the entry point for the RTR pipeline. Without it, downstream RTR components have no data to process. |
| When you need it | When your jurisdiction chooses NBS Core + RTR or NBS Complete. |
| Dependencies | Requires the NBS database (NBS_ODSE) as its source. Streams data to the Kafka cluster. |
Apache Kafka is an open source event-streaming platform. Kafka Connect is the framework that moves data between Kafka and other systems.
| Attribute | Description |
|---|---|
| What it does in NBS 7 | Acts as the message bus for the RTR pipeline. Kafka receives change events from Debezium and delivers them to the RTR domain services. Kafka Connect writes the processed output to RDB_Modern staging tables for post-processing and reporting. |
| When you need it | When your jurisdiction chooses NBS Core + RTR or NBS Complete. |
| Dependencies | Receives events from Debezium. Delivers messages to RTR domain services. Kafka Connect writes processed data to RDB_Modern. Requires sufficient cluster resources — Kafka is one of the more operationally demanding components in the RTR stack. |
A unified Spring Boot service that transforms streaming data from Kafka into reportable public health records. Previously implemented as five separate entity-specific services (investigation, person, observation, organization, and LDF data), these are being consolidated into a single reporting-service application to reduce deployment complexity and operational overhead.
| Attribute | Description |
|---|---|
| What it does in NBS 7 | Consumes Kafka messages for each entity type (investigations, patients, organizations, observations, and LDF data), runs stored procedures to retrieve and format the data, and produces processed records for downstream storage in RDB_Modern. A post-processing service then populates analytical datamarts and fact tables from the staging data. |
| When you need it | When your jurisdiction chooses NBS Core + RTR or NBS Complete. |
| Dependencies | Requires Kafka (message source) and NBS_ODSE (operational data store). Populates RDB_Modern staging tables, which are then consumed by the post-processing service. |
The five entity-specific RTR services (investigation-service, person-service, observation-service, organization-service, ldfdata-service) are being consolidated into a single
reporting-serviceas of early 2026. Check with your CDC NBS point of contact for the current deployment state.
The modern reporting database introduced by RTR.
| Attribute | Description |
|---|---|
| What it does in NBS 7 | Stores processed, structured public health records produced by the RTR domain services. Runs alongside the legacy RDB during migration. Downstream reporting and analytics tools connect to RDB_Modern rather than directly to the operational database. |
| When you need it | When your jurisdiction chooses NBS Core + RTR or NBS Complete. |
| Dependencies | Populated by RTR domain services. Required by any reporting or analytics tools that your jurisdiction connects to NBS 7. |