SPB Form 28 Last Revised 4-17-2025

SOLICITATION ADDENDUM 3

CHANGE IN SCOPE & PROCEDURE

SOLICITATION NUMBER: 202591102

STATEWIDE NG911

DATA ANALYTICS AND REPORTING SYSTEM

Opening Date: September 2, 2025 Addendum Effective Date: August 4, 2025

Change in Scope & Procedure

The following changes to the proposal are outlined in legislative format below. Any changes not included in this addendum or another addendum remain in full force and effect.

Section D. Deliverables is hereby amended as and incorporated follows:

D. DELIVERABLES

The proposed NG9-1-1 reporting system must deliver capabilities across the following areas. Each area includes detailed technical specifications, specific references to relevant NENA standards, and PSC-specific mandates.

Architectural Compliance:

• Adherence to NENA's architectural standards for NG9-1-1.

• Full support for the NENA i3 architecture, including the Emergency Services IP Network (ESInet) and IP-based call routing.

Data Integrity:

• Accurate and complete data transmission and reception.

• Validation of data against predefined schemas and data dictionaries as specified in the NENA data standards.

• Comprehensive logging of all data transactions, including timestamps, user IDs, and data changes, for auditing and troubleshooting.

• Support for configurable data validation rules to ensure completeness and accuracy, with customizable error handling procedures.

Security Measures:

• Implementation of robust security measures, including firewalls, intrusion detection systems, and data encryption.

• End-to-end encryption of all data in transit using TLS 1.3 or higher.

• Encryption of all data at rest using AES-256 or higher encryption standards.

• Multi-factor authentication (MFA) for all user access.

• Regular security audits and penetration testing conducted by certified third-party firms, with remediation of identified vulnerabilities.

• Compliance with industry security standards such as NIST 800-53 and ISO 27001, including implementation of relevant security controls.

• Intrusion Detection and Prevention Systems (IDPS) with real-time monitoring and automated response capabilities, adhering to industry best practices.

Interconnection Reporting:

• Demonstration of interoperability with other 911 systems and related platforms.

• Real-time monitoring of interconnection status, including uptime, latency, and error rates, with automated alerts for critical issues.

• Detailed reporting on call routing and handover success rates, providing insights into interconnection performance.

• Comprehensive logging of all interconnection events, including call setup, teardown, and error messages, for troubleshooting and analysis.

Operational Performance:

• Monitoring of call volume, call handling times, and response times.

• Real-time monitoring of call metrics, including call setup time, call duration, call termination reason, and call quality metrics (e.g., MOS score).

• Historical reporting and trend analysis capabilities, allowing users to identify patterns and track performance over time.

• Customizable dashboards for visualizing operational performance, with drill-down capabilities to investigate specific issues.

• Automated reporting on key performance indicators (KPIs).

Data Reporting:

• Comprehensive reporting on emergency calls, including caller location, emergency type, and response times.

• Support for standard data formats such as XML and JSON for data exchange and integration.

• Generation of ad-hoc reports and custom queries allowing users to retrieve specific data sets.

• Data export capabilities in various formats, including CSV, Excel, PDF, and JSON, for easy sharing and analysis.

Real-time Data and Analytics:

• Provision of real-time data and analytics on emergency calls.

• Integration with data visualization tools for interactive dashboards and data exploration.

• Predictive analytics capabilities for forecasting call volume, resource allocation, and potential emergency situations, leveraging machine learning algorithms.

Network Performance:

o Monitoring of the proposed statewide NG911 Data Analytics and Reporting System’s network latency, packet loss, and jitter.

• Real-time monitoring of the proposed statewide NG911 Data Analytics and Reporting System’s network performance metrics, including latency, packet loss, jitter, and bandwidth utilization, with customizable thresholds and alerts.

• Automated alerting on network performance degradation, enabling proactive troubleshooting and issue resolution.

• Historical reporting and trend analysis of network performance allowing users to identify patterns and optimize network configuration.

• Expected uptime equal to 99.9% or greater annually.

Service Quality:

• Measurement of call completion rates and call handling times.

• Automated analysis of call logs providing insights into potential issues.

• Reporting on service quality metrics such as call delivery type, call success rate, and network performance, with drill-down capabilities to investigate specific issues.

• Management of statewide reporting system.

Deliverable Flexibility:

• Deliverables may be pre-defined or proposed by vendors but must align with the RFP’s cost and structure.

Deliverables are subject to the Deliverable Approval Process, contained in the terms and conditions.

Section E. Technical Requirements Subsection 1.5 is hereby amended and incorporated as follows:

Data Collection & Integration

The system must automate data collection from NG9-1-1 components, including PSAP Call Processing Equipment (CPE), and support transformation/enrichment for analysis. Integration with CAD systems and third-party APIs is required, alongside buffering for legacy Call Detail Records (CDRs) to prevent data loss.

The proposed system must support the automated collection of data from all core NG9-1-1 components, ensuring continuous ingestion of real-time call and operational information. The solution must provide capabilities for logging detailed call metadata as calls occur, with precision time-stamping. Data transformation and enrichment tools must be included to enable users to clean, normalize, and augment raw data, thereby improving the quality and usability of information for downstream analysis. Vendors should demonstrate how their solution ensures data completeness, supports both structured and unstructured inputs, and facilitates seamless integration with analytics and reporting workflows.

Section E. Technical Requirements Subsection 1.7 is hereby amended as follows:

The system must be designed for seamless interoperability with existing 9-1-1 infrastructure, including databases, and CPE, and CAD Systems. It must support standard communication protocols and data formats, and provide well-documented APIs for integration with third-party platforms and applications. Compatibility with the current technology environment is critical to minimize disruptions during deployment. The vendor must offer training to ensure end users can fully utilize reporting tools and system capabilities. The system must support web-based access to avoid local software installations and offer intuitive tools for exporting raw data (e.g., Excel or web interfaces) to support local analysis. Dashboards must be tailored for PSAP-level use, including heatmaps, peak demand analysis, and administrative briefing tools. Future system enhancements, such as multimedia reporting and integration, should be supported. Local data ownership must be retained while enabling flexible access at the state or PSC level.

Role-based access controls (RBAC) to reporting must allow the Public Safety Communications (PSC) agency to access reports at the statewide level, while providing granular access options for PSAP-specific users. This includes differentiated access for administrators, supervisors, and users with restricted visibility based on their roles. Dashboards must be web-based, role-aware, and customizable to reflect user-specific views, incorporating “drill-down” capabilities to explore summary data at a more granular level.

• Scalability: The system must be able to handle adding PSAPs and users without creating customization and increasing call volumes and data loads without performance degradation. Provide detailed information on the system's scalability architecture and testing results.

• Maintainability: The system must be easy to maintain and update, with automated monitoring and alerting capabilities. Provide details on the system's maintenance and support procedures.

Section E. Technical Requirements Subsection 2.3 is hereby amended and incorporated as

System shall Identify or Differentiate Test Calls Call Anomalies from Normal System Usage

The proposed system must have a built-in capability to distinguish test calls call anomalies from standard operational calls. This differentiation should be automated, enabling system administrators to identify anomalies in normal call traffic such as repeated routine calls from the same telephone number from routine traffic. test calls, transfer test calls, and other testing of the system from actual call traffic. The test call differentiation should include the ability to separate transferred calls to avoid double counting of calls when they are transferred. This feature is critical for maintaining data integrity in reporting and performance monitoring, as test calls and transfers must be excluded from KPIs such as average handling time, abandonment rate, or data to establish staffing requirements. The system should provide a filter or flag within its reporting tools to isolate or exclude test call data from operational analytics.

Section E. Technical Requirements Subsection 6.0 is hereby amended and incorporated as

6.0 Operational Reporting

At a minimum, the following data elements will be readily available for reporting purposes at the system level and at the PSC/PSAP level:

• Call Type

• Payload Processing Times

• Answer Time (Agent Answer time, PSAP Answer Time, Caller Answer Time)

• Disconnect Time

• Incoming IP Address

• Pre-Defined Reports – restricted to PSAP(s) based on user role.

• Total Count of Payloads by Type

• Average Event Waiting Report

• Average Event Duration

• Total Abandoned Events

• Events by Incoming IP Address

• Events by Hour of Day

• Events Answered by User ID

• Events by Day of the Week

• Events Transferred from PSAP

• Event Transferred to PSAP

• Position Answered

• Events Answered by Position

• Events Answered by All Positions

• Agent Availability Report

• Call Volumes

• Individual Call Detail Information

• Collection of Calls

• Summary of Call Loads

• Caller Ring time

• Events by Month

• All legs of call

• Overflows

• Transfer origin

• Transfer destination

• County field

• Rapid SOS Third-party populated fields (Lat/Lon)

• Uninitialized events

Section A. Solicitation Response Submission, number 3 is hereby amended and incorporated as

3. RESPONSE TO PROJECT REQUIREMENTS AND SCOPE OF WORK

Bidder should read the Project Requirements and Scope of Work Section of this RFP and provide a response to each section as part of its proposal. This response should describe how the bidder will complete the scope of work, fill in any additional steps or details necessary, and demonstrate why the bidder is the most qualified or capable.

Further, the response should contain responses to the following requests or questions:

Additional Note: The response should not contain any reference to dollar amounts. However, information such as data concerning labor hours and categories, materials, subcontracts and so forth, may be considered so that the bidder’s understanding of the scope of work may be evaluated.

This addendum will be incorporated into the solicitation.