IPTD-571
WSGS Emergency Response Incident Tracking and Dashboard / (Legionella Disruptions)
Description
-
Implement Correct Division Business Logic and Data Flow for Water Supply Disruptions
The system should allow Emergency Response Coordinators (ERC) to define the "path" and "category designation" for classifying disruption incidents as they come in. Depending on the assigned category, the appropriate process flow will track and manage each subsequent step in the process.
-
E-Mail Alert Escalation/Awareness Once ERC defines the disruption event “category”, a pre-set email sequence shall be triggered. Depending on the category, various groups will automatically be sent an e-mail notification. Detailed email triggers and recipient lists will be finalized in system design sessions. Email alerts will be sent to internal DEP staff and the public based on system-defined groups. Emails will include attachments like situational reports related to the current water supply disruption.
-
Administration Control Panel This section will enable DEP staff to manage and support the system. User Account and Role Management (Number and type of roles to be defined during design sessions). Email Accounts and Group Management
-
Public and Internal DEP Dashboards Two distinct dashboards are required: one for public use and a more detailed version for the DEP.
-
Statewide Dashboard in the Form of Interactive Map Available to both the public and DEP. Example: Aqua Disruption Viewer Color-coded interactive map display of NJ emergency incident status for water systems affected (Ongoing, Advisory Issued, Incident Closed). How long to keep closed incidents viewable to be discussed at design sessions. Points on interactive map open a station dialog with details and status information when clicked. Pre-embedded links that take user to the Water System overseeing the water supply disruption. For smaller water systems without public web pages, the Division must quickly supplement information in the interactive map’s station dialog box such as an updated URL. A system for Division staff to publish or update content immediately for the interactive map will be necessary. We would like the system to have the capability to automatically generate and display a GIS layer that shows water systems with current violations. This GIS layer should be created through an automated process in the background and should use data from the Safe Drinking Water Information System (SDWIS) database. Additionally, the layer needs to be updated every hour so that DEP/Public are seeing real-time status.
-
Summary Graph/Table Dashboard This feature, exclusive to the DEP, will track disruption events over time. It will generate tables and graphs to offer the Division essential statistics, enabling quick summaries and detailed insights related to these events. Shall have the capability to summarize data across all historical periods, not just the current year. Details of what to include in the table/graphs and how many to be discussed at system design sessions.
-
Document Upload / Form Submission Capability Not all data related to emergency events is currently sent to or stored at the DEP. Therefore, a submission portal for outside water systems needs to be developed to enable the DEP to receive missing incident-specific information. Regulations will require Owners/Operators (outside GSN) to upload incident-related documents, necessitating a system with the capacity to store and retrieve these attachments later. The immediate need is to store PDF attachments, like "flushing plans," with each incident.
-
Unified Data Integration for Emergency Disruption System A key challenge in creating a cohesive emergency disruption system is scattered data. We need to link and synchronize this information to develop interactive maps and dashboards. A streamlined solution is essential to consolidate data into a single, reliable endpoint for staff access and reference. All stored data (Table/Columns and Attachments) to be easily accessible by staff. The solution will allow staff to use DEP tools like SQL Developer for direct queries, ensuring data is easily accessible. Staff must have easy access to data; any barriers to access will be deemed unacceptable. At the emergency disruption “close out”, ideally the tool would export data & files into an activity in NJEMS/PEGA for long term data retention.
-
Response Times Ensure the interactive map and dashboard have rapid response times to provide users with a seamless experience. The system must be optimized for speed to prevent delays and maintain efficiency.
Problem Statement
Project Justification
Recent legislation requires the Division of Water Supply and Geoscience to establish a data repository, tracking system, and public dashboard for water system "disruptions" to reduce the risk of Legionella and Legionnaires' disease.
DWSG would like to leverage this opportunity to better manage all water supply disruptions, extending beyond those related to Legionnaires' disease, by creating a data repository, implementing emergency email notifications, and developing a public-facing interactive map and dashboard.
Meeting was held between DOIT/Carrollton on 3/11/26. Carrollton demoed EJ and discussed some features (ability to access/query NJEMS, email/text notifications, and administrative user management) that could be leveraged for this project. Action Items: (1) Program to look at this demo video to get familiarized with EJ, and then for me to schedule a second DOIT/Carrollton/WSGS demo where the program can ask specific questions. (2) Try to get someone from Water Enforcement to demo the incidents module. I’m still working on that one.
from email by Mike K. to the team (WRM and DOIT) on 3/6:
Max/Xena:
Copying everyone involved on this project so we’re all on the same page.
DOIT has been discussing the deliverables for the "Legionella Disruptions - Emergency Response Incident Tracking and Dashboard – IPTD 571" project. We met today to outline next steps and what is needed to make this project move forward. Here's what needs to happen for the project to advance:
Demo of Incident Module: DOIT believes we can leverage the existing Pega Incident Module to satisfy some of the deliverables listed for this project. Although this is a Water Supply & GeoScience (WSGS) project, Water Enforcement (WE) has more experience with Incident Modules. We would like to request that a subject matter expert from WE conduct this demo to the WSGS and DOIT team, with Mike McCormack from DOIT available for technical questions. The objective will be to evaluate whether minor or major adjustments are needed to align with the envisioned process flow and to assess the potential of the Incident Module concept for this project. This step is crucial for determining the project's direction and we should try to name and schedule a demo date as soon as possible.
Action Item: Trish to request from Linda a person to demo the Incident Module and provide DOIT and myself with that person’s name.
Environmental Justice (EJ) Application: Carrollton, who developed the EJ application, suggests adapting some concepts from the EJ project to meet the needs of the IPTD 571 project. On 3/11/26, Carrollton will meet with DOIT to discuss potential adaptations. If promising, a second demo will be scheduled with WSGS for further input and comments.
Action Item: DOIT will evaluate what Carrollton's has to say, then make the determination if it warrants a demo with WSGS to layout a vision for moving forward.
Tableau vs. ESRI Experience Builder: This is another critical decision for the project path. DOIT needs feedback on the current Incidents Dashboard https://intranet.dep.state.nj.us/depnet/incidents-dashboard/. If this dashboard conceptually fits with what WSGS envisions, integrating emergency incident points and a water system boundary GIS layer may be feasible utilizing Tableau. If more intense GIS functionality is required, we will need to move more towards an ESRI based solution.
Action Item: WSGS team to assess the dashboard’s GIS flexibility (https://intranet.dep.state.nj.us/depnet/incidents-dashboard/) and report back to Mike Matsko and Vaughn Smith. Feedback will guide the decision between Tableau or an ESRI based interactive map.
We should try to have responses back to DOIT no later than end of day Wednesday 4/11/26 to keep this project moving forward.
Carrollton reviewed the IT Project Sheet and work flow attached to this IPTD, and provided an initial assessment on whether the Notification Requirements would be a good fit for the Public Notification Platform they built (being used initially for EJ Notifications). They indicated that it seems like a good fit provided the notification “Triggering Event” came from NJEMS (e.g. an Incident created in the incident module of NJEMS). They stressed that the GIS/Map functionality built into the notification system would require that DEP develop the map up-front. A meeting is being set up with Carrollton to discuss more detail ON THE NOTIFICATION REQUIREMENTS ONLY, so that an initial high-level LOE can be determined for integration into the Notification System. The remaining next steps and follow-up items listed below still need to be scheduled/finalized.
meeting today with program and DOIT - Recap: WSGS Emergency Response incident Tracking and Dashboard/(Legionella Disruptions) Project - Next steps Thursday, February 12 | Meeting | Microsoft Teams
see copy of AI summary:
Generated by AI. Be sure to check for accuracy.
Meeting notes:
Existing Incident Reporting and Notification Systems: Jim, Mike Matsko, and others discussed the capabilities of the current incident reporting module in NJEMS and the associated notification systems, emphasizing that most required features for water system incident tracking and public notification are already available and can be configured for new needs.
NJEMS Incident Module Functionality: Jim explained that the NJEMS incident module is used to log almost all incidents, which can be linked to activities, enforcement, and APIs, and is geospatially enabled for water systems. The module supports notifications and is integrated with other systems for broad incident management.
Notification System Integration: Jim described a configurable notification system built for environmental justice (EJ) in Pega, using GovDelivery for mass email notifications, which is already hooked into NGEMS and can be minimally tweaked for water system incidents.
Subscription and Trigger Mechanisms: Citizens and organizations can subscribe to notifications based on geospatial criteria or specific facilities, with triggers such as incident logging in NGAMS initiating email broadcasts via GovDelivery.
Workflow and Data Routing: Mike Kusmiesz and Jim confirmed that the incident module supports routing incidents into different management buckets, allowing for upward management notification or less urgent handling, and that this workflow is already established within the system.
Dashboard and Mapping Requirements: Mike Matsko, Mike Kusmiesz, Vaughn, and Brandon discussed requirements for interactive dashboards and mapping, comparing Tableau and GIS solutions, and explored the feasibility of integrating mapping layers and real-time data for public and internal use.
Tableau vs GIS Capabilities: Mike Matsko outlined the strengths and limitations of Tableau for interactive mapping, noting that while Tableau can display points, color coding, and basic spatial analysis, it lacks robust GIS features such as web services and multiple layers, which are available in ArcGIS Online (AGO).
Dashboard Interactivity and Data Entry: The group clarified that Tableau dashboards are read-only and cannot support direct data entry or modification, but data can be edited in NJEMS or the incident module before being displayed in Tableau.
Mapping Layer Integration: Brandon and Mike Matsko discussed the possibility of adding purveyor polygons and other service area layers to Tableau dashboards, with Vaughn agreeing to investigate technical feasibility and Brandon providing access to the relevant data layer.
Real-Time Data and User Expectations: Brandon emphasized the need for dashboards to be as close to live as possible to meet public expectations for timely information on incidents such as water main breaks, and Mike Matsko noted that requests for real-time data integration had been initiated with OIT.
Data Submission and Reporting Needs: Angela, Jim, Mike Kusmiesz, and Brandon discussed the need for water systems to submit sample results and other data through a platform rather than email, considering options for facility submittal services and integration with existing systems like RSP and E2.
Current Data Submission Challenges: Angela highlighted issues with relying on email for receiving clean coliform results and other data from water systems, noting that missed emails can delay lifting boil water advisories and that SIDWISS cannot house these sample results.
Facility Submittal Service Proposal: Jim proposed building a facility submittal service within RSP, allowing water systems to log incidents, upload follow-up data, and leverage existing RSP usage among water systems for streamlined data submission.
Data Parsing and Query Requirements: Mike Kusmiesz and Angela discussed whether submitted data needs to be tracked as spreadsheets or parsed for statistical analysis, with Brandon noting the preference for queriable data but acknowledging practical limitations.
Integration with E2 and Other Systems: The team considered using E2 for new report types that do not go into SDWIS, referencing its use for private well testing and discussing the need for further conversation to clarify requirements and best approaches.
Stakeholder and Customer Considerations: Knute and Brandon discussed the legislative mandate driving the project, the dual focus on internal process improvement and public awareness, and the need to balance sensitive information sharing with public transparency.
Legislative Mandate and Broader Vision: Knute noted that the project originated from a legislative mandate related to Legionnaires' disease but should be designed to handle a wide range of incident reporting needs, with Brandon confirming the intent to pair external requirements with internal process improvements.
Internal and External Stakeholder Needs: Brandon described the goal of improving emergency incident tracking and sharing information with internal agency partners and external agencies, as well as providing public-facing tools for citizens to understand incidents in their communities.
Sensitive Information Management: Brandon and Knute discussed the need to restrict certain incident details to authenticated partners rather than the public, to avoid exposing sensitive information about utilities or infrastructure, and considered the use of authentication and group-based notifications.
Customer Experience and Resource Integration: Knute suggested integrating water incident information with existing public resources to create a comprehensive picture for citizens, prompting discussion on how the new platform could enhance public understanding of local environmental issues.
Next Steps and Action Items: Jim, Mike Matsko, Vaughn, and others outlined next steps including demos of the incident module and EJ notification system, sharing existing dashboards for review, and further meetings to clarify requirements and technical feasibility.
Incident Module and Notification System Demos: Jim committed to setting up demonstrations of the incident/enforcement workflow and the EJ notification system, involving Mike McCormick and Sam Njuki, to help stakeholders understand current capabilities and identify enhancement needs.
Dashboard Review and Feedback: Vaughn agreed to locate and share an existing incident tracking dashboard for group review, with Glenn posting it on a DEP-only page to allow stakeholders to explore real data and provide feedback on desired mapping functionality.
Technical Feasibility Investigations: Mike Matsko and Vaughn planned to test the integration of purveyor polygons and other layers into Tableau Cloud dashboards, coordinating with Shreyas and leveraging Brandon's data link.
Requirement Clarification Meetings: Jim and others emphasized the need for further meetings between water system stakeholders and technical teams to clarify incident process requirements, data needs, and determine whether enhancements or new development are necessary.
Follow-up tasks:
Incident Module and Enforcement Workflow Demo: Set up a demo of the current incident/enforcement workflow and the EJ notification system for the water team to review capabilities and enhancements needed. (Jim, Mike McCormick, Sam Njuki)
Incident Dashboard Access: Locate the existing incident tracking dashboard and make it available via a shareable internal link for the group to review and provide feedback on mapping functionality. (Vaughn)
Water System Service Area Layer Integration: Share the purveyor polygons (service area layer) link with Vaughn and Mike Matsko to explore integration into the incident dashboard for mapping purposes. (Brandon)
Service Area Layer Dashboard Testing: Work with Shreyas to attempt adding the water system service area layer to the incident dashboard in Tableau Cloud and assess feasibility. (Vaughn, Mike Matsko)
In addition to the project IT Sheet, program added an emergency response flow chart with some brief explanations at each stage so that DOIT and Contractor can better understand what the program is envisioning.