addendum-7-rfp-dos-2026-02.pdf

RFP DOS 2026-02 Page 1 of 9

RFP DOS 2026-02

Crash Data Analysis System

Addendum 7

Vendor Questions & Answers

Vendor Q&A RFP-DOS-2026-02 Crash Data Analysis System

Section/Reference Question Response

Business Requirements: B.1.21: The system shall retain twenty years of data, which is the NH requirement for fatality crashes.

Business Requirements: B.4.2: The NH DOS/DOT shall provide complete crash records for the past 10 years, which will need to be fully incorporated into the new software system.

The RFP states that OHS is looking for a recommendation as to how many years of crash data should be made available. In requirement B1.21 it states that “twenty years of data, which is a NH requirement for fatality crashes” is required and in B.4.2 it states “The NH DOS/DOT shall provide complete crash records for the past 10 years, which will need to be fully incorporated into the new software system.” Can OHS clarify what crash data will be provided to the proposer and what the total number of years and volume of data is that we should anticipate needing to incorporate? Is OHS looking for the proposer to incorporate the data as-is or will data cleansing and standardization be part of the scope of work?

The system should be capable of retaining a full historical record of Crash Data, provided through the NH Data Warehouse, which will be standardized and cleansed. The system should have the ability to meet the records retention policies as dictated by the State of New Hampshire. Retention requirements will range from 10-20 years.

Data Cleansing will not be required by the Vendor as part of the Crash Analysis System.

Data Format

What format(s) are the VISION data stored in? For example, PDF vs plain text.

The Crash Analysis System will not interface with the Vision system directly. It will interface with a Data Warehouse, which is housed in an Oracle 19c relational database.

Data Sets

How large is the VISION data set? (Number of records, number of Gb)

Roughly 6GB.

Data Sets

What proportion of existing crash reports are handwritten?

Roughly 60% including historical reports.

RFP DOS 2026-02 Page 2 of 9

Data Sets

What proportion of existing crash reports are geocoded? Most electronic crash reports are geocoded before they enter Vision, NHDOT historically geocodes any crash report record that it receives from DMV. The State intends on geocoding all crash records by 2027.

Solution Expectations & Design

How does the agency currently prepare collision diagrams?

The State and Local Law Enforcement Agencies use their CAD/RMS systems to draw the collision diagrams. In some cases, these are drawn using VISIO, MS Word, or a third-party sketch tool. The diagrams are saved in the form of an image file. Most diagrams are in JPG format.

Solution Expectations & Design

Does the agency have an existing technology stack (e.g., GIS, analytics, dashboard platforms) that the proposed solution is expected to integrate with or align to?

The core components of the Data Warehouse are Oracle and Informatica. NHDOT currently uses Esri products for GIS mapping. The proposed solution should be capable of processing data from relational database flat (fixed length or CSV) files.

Data & Integration

Are there any mandated or preferred data sources, technology platforms, or service providers (e.g., GIS vendors, visualization frameworks) that proposed solutions must integrate with?

We expect the Crash Analysis System to be able to pull data from relational database flat files.

Having capability in the tool to invoke SOAP or REST style web services will be an added advantage. We also require a service that can integrate with Esri products. The solution should also be capable of integrating with the feeds listed below as outlined in Business Requirement B3.5, and be flexible enough to handle additional feeds in the future.

• DMS Messages

• Environment Sensor Data (road temperature, precipitation, etc.)

• Incidents (hard braking, road construction, etc.)

• Lane Closures

• Network Information (Travel Times and Roadways)

RFP DOS 2026-02 Page 3 of 9

• Travel Conditions

• Travel Times

• Traffic Incidents

• UNH GranitView

Compliance & Hosting

Does the agency have an existing FedRAMP or StateRAMP authorization boundary that proposed solutions are expected to operate within?

The State expects that the Vendor will clearly define the authorization boundary of their product.

NIST SP 800-37 defines an authorization boundary as "all components of an information system to be authorized for operation, also known as in-scope components, and excludes separately authorized systems or systems that lack a [StateRAMP] authorization, also known as out-of-scope components, to which the information system is connected."

This document provides guidance for developing authorization boundaries for cloud offerings:

https://s33104.pcdn.co/wp-content/uploads/2023/06/StateRAMP- Authorization-Boundary-Guidance-v1.1.pdf

Staff Qualifications

Are you looking for a NH-registered PE to be part of the project team?

The State does not require that an NH-registered PE be part of the project team, but we do require the team to have expertise in the following areas, as outlined in Appendix D, Section 3 of the RFP:

PE license in Transportation or a road safety professional with equivalent experience, GIS specialist, and IT API Integration Specialist.

Project Cost

What is the anticipated budget for this project? The Vendor will provide the cost of their solution with their submission, and the State will evaluate and score the price proposal separately from the technical solution. Funding is available in the biennium 26/27 budget.

RFP DOS 2026-02 Page 4 of 9

Section 2.4

The RFP outlines scoring related to FedRamp/StateRamp authorization, indicating that the offeror must have FedRamp or StateRamp status to gain full points.

Typically, FedRamp or StateRamp are pertinent to cloud service providers (e.g. AWS); whereas Software-as-a- Service providers might more typically show their security compliance through an authorization such as SOC 2. Could a SaaS focused compliance authorization in lieu of this cloud one, such as SOC 2 compliance or another such authorization, satisfy the security requirements of this section?

Yes. StateRAMP and FedRAMP are preferred, but not required.

StateRAMP

StateRAMP has now rebranded as GovRAMP as best we understand (reference:

https://govramp.org/blog/stateramp-announces-rebrand-to-govramp-reflecting-mission-to-unite-public-and-private-sectors-in-advancing-cybersecurity/). Is this the compliance authorization being referenced within this

RFP?

Yes - GovRAMP (formerly known as StateRAMP) and FedRAMP.

Topic 4, Question 9

The RFP asks the vendor to articulate the right process to identify the appropriate number of years of historical crash data to import. Is there a minimum number of years New Hampshire is interested in seeing?

The State retention requirements vary depending on the severity of the crash, primarily whether a fatality is involved. Retention requirements will range 10 to 20 years.

Historical Data

Please clarify the crash history expectations for the System. One of the project requirements is to "retain twenty years of data, which is the NH requirement for fatality crashes" while another states that "The NH DOS/DOT shall provide complete crash records for the past 10 years." Does this mean the legacy system will remain in service for another decade as a repository of crash records that are 11-20 years old as of the date of cutover to the new system?

The system should be capable of retaining a full historical record of Crash Data, provided through the NH Data Warehouse, which will be standardized and cleansed. The system should have the ability to meet the records retention policies as dictated by the State of New Hampshire. Retention requirements will range from 10-20 years.

RFP DOS 2026-02 Page 5 of 9

Appendix E: Summary table 1.7

Are the total prices for 1.4 - Software Operations, Maintenance, and Support Pricing, 1.5 - Hosting Pricing, and 1.6 - Other Pricing, intended to cover year 1 costs or multiple years (e.g. 5 years, 7 years, etc.)?

The total prices should cover the extent of the five-year contract as well as the optional additional two years. The pricing tables are formatted to show total cost per year for Software, Hosting, etc.

Requirement B4.2

"The NH DOS/DOT shall provide complete crash records for the past 10 years, which will need to be fully incorporated into the new software system." What is the volume of this data? This will allow us to estimate the time for migration and the cost of the migration infrastructure. Please elaborate:

1. Data volume: total size (GB/TB) and number of records

2. Data complexity: Number of tables, fields, complexity of schema

3. Data sources: Current systems/platforms

4. Data quality: Accuracy, completeness, and consistency

5. Transformation needs: Complexity of required data transformation (mapping, cleansing, enrichment)

6. Testing and validation: Acceptance criteria for data validation post-migration

7. Resource availability: Customer resource availability for validation and signoff

1. Data Volume is approximately 8-10 GB.

2. Data Complexity: We are currently in the process of designing and implementing the Data Warehouse. We anticipate the total number of tables to be around 60-75.

3. Data Sources: For the Crash Analysis System, it will be one single source in the form of a relational database.

4. Data Quality: The data quality of the Data Warehouse depends upon the data present in the source OLTP systems. The Data Warehouse during its ETL stage will perform the data quality and enrichment transformation.

5. Transformation Needs: All transformation-related steps such as data cleanup and formatting, will happen in the Data Mart. We do not expect the Crash Analysis System to do any such activities. However, there may be some transformations needed for data visualizations, which the vendor's solution is expected to handle.

6. Testing and Validation: The business users will be responsible for development and execution of the User Acceptance Test cases.

7. Resource Availability: The business users will be available for the validation and signoff. The DoIT internal team involved in building the Data Warehouse will work closely with the Crash Analysis System vendor during the integration and testing phases.

Requirement B1.1

"The System shall compile metrics from disparate data sources to produce a comprehensive list of crash metrics.” What are the disparate datasets that are expected to produce crash metrics, other than standard crash data. Can you please provide some examples?

We expect the Crash Analysis System to be able to pull data from relational database flat files.

Having capability in the tool to invoke SOAP or REST style web services will be an added advantage. We also require a service that can integrate with Esri products. The solution should

RFP DOS 2026-02 Page 6 of 9 also be capable of integrating with the feeds listed below as outlined in Business Requirement B3.5, and be flexible enough to handle additional feeds in the future.

• DMS Messages

• Environment Sensor Data (road temperature, precipitation, etc.)

• Incidents (hard braking, road construction, etc.)

• Lane Closures

• Network Information (Travel Times and Roadways)

• Travel Conditions

• Travel Times

• Traffic Incidents

• UNH GranitView

StateRAMP

In the case of a proposal involving multiple partners, is it sufficient for the prime (responding) vendor to hold StateRAMP authorization, or must all subcontractors and partners also meet the StateRAMP requirements?

Please refer to RFP Section 4, Item 2.4. "If the vendor’s solution (Hosting and Product) is fully FedRAMP or StateRAMP authorized, and within periodicity, the Vendor score for this section shall be awarded at 15% of the total possible points for the technical solution. If only the Vendor’s Hosting environment is FedRAMP/StateRAMP authorized the vendor will be awarded 5% of the total possible points for the technical solution."

In addition, when you submit your proposal response to Appendix C, Topic 5 (System Security) where you provide your corporate qualifications and those of any Subcontractors proposed to participate in the Project, you may incorporate StateRAMP certification for subcontractors in that portion of your response.

StateRAMP

If a semi-custom solution is proposed, would hosting that solution in a cloud environment that is already StateRAMP authorized meet the compliance requirements, even if the application itself is not independently certified?

Please refer to RFP Section 4, Item 2.4. "If the vendor’s solution (Hosting and Product) is fully FedRAMP or StateRAMP authorized, and within periodicity, the Vendor score for this section shall be awarded at 15% of the total possible points for the technical solution. If only the Vendor’s Hosting environment is FedRAMP/StateRAMP authorized the vendor will be awarded 5% of the total possible points for the technical solution."

RFP DOS 2026-02 Page 7 of 9

In addition, when you submit your proposal response to Appendix C, Topic 5 (System Security) where you provide your corporate qualifications and those of any Subcontractors proposed to participate in the Project, you may incorporate StateRAMP certification for subcontractors in that portion of your response.

Requirement B1.10

"The System shall, at a minimum, comply with the safety performance methods described in Highway Safety Manual Part B." In addition to complying with the Model Minimum Uniform Crash Criteria (MMUCC), are there any state-specific data standards or customizations required?

There are no additional data standards required beyond federal and New Hampshire MMUCC standards. The State will provide the awarded vendor the New Hampshire MMUCC schema.

Requirement B1.11

"The system shall compile crash data from multiple sources and produce a prioritized list of locations for safety improvements, based on crash types and severity."

We assume the crash data from multiple sources are in a uniform format. Please confirm. Please list the different sources of crash data for estimation and planning. Do these sources provide REST APIs for integration or is this based on file transfer/batch processing?

The data will be made available in a uniform format. We are designing the Data Warehouse with a specific Data Mart for crash data reporting. It will be exposed in the form of a set of relational database tables. The current plan is to expose three separate data sets - one each for Paper Crash Reports, MMUCC4, and MMUCC5.

In the future, support of MMUCC6 will also be added. We may expose a uniform data set exposing the highest common factor between Paper, MMUCC4, MMUCC5, and MMUCC6 data sets. No SOAP/REST API is being planned to expose the data. There is no need for file transfer or batch processing as data is present in a relational database. However, the tool may have a need to implement batch mode for data ingestion.

Requirement B3.2

"The system shall have the ability to ingest data from structured (RDBMS system, csv, Excel) and semi-structured (JSON,XML) data sources". Is this going to be a continuous integration or a one-time integration?

We expect the Crash Analysis System to have the capability to pull data and present various forms of business intelligence reporting and data visualizations per date ranges. It should refresh data based on user actions. It will be a continuous integration, which the tool may want to implement as real-time or in batch mode for data ingestion.

RFP DOS 2026-02 Page 8 of 9

Requirement B3.5

"In addition to internally-sourced State agency data, the following data feeds shall be ingested to enhance the crash reporting and analysis through the New England 511 Network:

CCTV Snapshots and Camera Status, DMS Messages, Environment Sensor Data (road temperature, precipitation, etc.), Incidents (hard braking, road construction, etc.), Lane Closures, Network Information (Travel Times and Roadways), Travel conditions, Travel times, Travel incidents, UNH GranitView"

CCTV Snapshots and Camera Status - Could you clarify the frequency and resolution, or quantitative data generated CCTV system required for integration, and how this data will specifically enhance crash analysis and reporting?

DMS Messages - Can you explain how you are planning to use dynamic message sign (DMS) data in crash analysis, and the expected frequency and format of these messages?

Environment Sensor Data (road temperature, precipitation, etc.) - What level of granularity and frequency of environmental sensor data is expected?

Please share your thoughts on how this data will contribute to crash prevention or analysis.

Incidents (hard braking, road construction, etc.) - Can you specify how incident data is correlated or integrated with crash reports, including the expected timeliness and sources of this data?

Lane Closures - Could you detail the anticipated workflow for integrating lane closure data into crash analytics, including how frequently this information needs to be updated and its expected impact on crash prediction or analysis?

Travel times - Please explain how travel time data is planned to be used in crash data analysis. How frequently should this data be refreshed and using what technologies/format?

Travel incidents UNH GranitView – Can you outline specific datasets

CCTV Snapshots: These have been removed from scope. Business Requirement B3.5 will be updated in an Addendum to reflect this.

DMS Messages: DMS messages display work-zone messaging and that may affect the type of crashes that occur in that zone.

Environment Sensor Data: Combining data from road sensors (e.g., traffic speed, volume, or weather conditions) with crash data (e.g., accident locations and times) can reveal patterns of synchronicity—events happening at the same time or in a coordinated way. These patterns can be used in predictive analytics to forecast potential accidents or traffic issues, enabling better prevention or response strategies.

Incidents: Combining ITS data (hard breaking, or road construction ITS beacons) with crash data (e.g., accident locations and times) can reveal patterns of synchronicity—events happening at the same time or in a coordinated way. These patterns can be used in predictive analytics to forecast potential accidents or traffic issues, enabling better prevention or response strategies.

Lane Closures: Combining lane closure data with crash data (e.g., accident locations and times) can reveal patterns of synchronicity—events happening at the same time or in a coordinated way. These patterns can be used in predictive analytics to forecast potential accidents or traffic issues, enabling better prevention or response strategies.

Travel Times: Combining travel time messaging with real-time speed data with crash data (e.g., accident locations and times) can reveal patterns of synchronicity—events happening at the same time or in a coordinated way. These patterns can be used in predictive analytics to forecast potential accidents or traffic issues, enabling better prevention or response strategies.

UNH GranitView: NH DOT roadway data is cataloged on GranitView, a University of New

RFP DOS 2026-02 Page 9 of 9 from the UNH GranitView platform that are critical for your crash analysis system, and clarify the anticipated frequency and method of integration?

Hampshire-operated website. Combining Construction project layers, VMT data, and node data layers with crash data (e.g., accident locations and times) can reveal patterns of synchronicity—events happening at the same time or in a coordinated way. These patterns can be used in predictive analytics to forecast potential accidents or traffic issues, enabling better prevention or response strategies.

Crash Location

Regarding crash location alignment using the Linear Referencing System (LRS), what is the expected frequency and format for location updates? Are historical roadway network versions available?

The historical roadway network versions are available as static files on GranitView. The State requires the LRS to be updated quarterly.

Requirement B10.3

"The customizations and data intake period shall not exceed three (3) months, except in the case of delays and/or modifications by NH DOS/DOT." Could the State clarify whether this 3-month window includes UAT, stakeholder sign-offs, and required security reviews?

Additionally, would phased go-lives or partial data onboarding be acceptable within this timeline?

The State will be flexible if additional time is required for UAT and Requirements definition.

Network Screening and SPF Computation

Is the NH ROADS coverage in GRANIT the preferred data source to support the desired network screening and SPF computation functionalities? Is there a comparable coverage with intersection geometrics and intersection traffic control type?

Yes. The NH DOT is currently developing the MIRE inventory, which will include intersection geometry and intersection traffic control. We will coordinate with the selected vendor when the MIRE inventory comes online.

NOTE: ALL CHANGES TO PROPOSAL SOLICITATION NOTED IN ADDENDUMS WILL SUPERSEDE PREVIOUSLY SUBMITTED DOCUMENTS AND

MUST BE SUBMITTED WITH THE PROPOSAL. ALL OTHER SPECIFICATIONS REMAIN UNCHANGED AND VALID.

BIDDER ____________________________ ADDRESS ____________________________

BY ________________________________ ____________________________

(this document must be signed)

________________________________ TEL. NO.____________________________ (please type or print name)