Knogin
[Developers]

Responder Critical Alert and Live ETA

A community first responder's phone displays a critical dispatch alert with one tap: incident type, priority level (P1 to P4), exact location, and a live ETA countdown updating every second as the nearest responder races

Back to All Modules
Category: CollaborationLast Updated: May 7, 2026
collaborationreal-timecomplianceblockchaingeospatial

Overview#

A community first responder's phone displays a critical dispatch alert with one tap: incident type, priority level (P1 to P4), exact location, and a live ETA countdown updating every second as the nearest responder races towards the scene. The responder taps Acknowledge and Response, and the dispatch system records the acknowledgement, rotates the primary responder if a closer unit became available, and the incident timeline updates in real time.

Responder Critical Alert and Live ETA delivers alerts to community first responders (CFRs) and nearest-unit field responders with a continuously-updating arrival time estimate rendered directly on the mobile device. The system finds active responders within a configurable proximity radius (default 2 kilometres), dispatches a high-priority alert with incident context, displays live ETA as the responder moves towards the scene, and captures acknowledgement. Every status change, location update, and rotation event lands on the canonical incident timeline so the controller maintains a complete picture of all responders and their arrival estimates.

Key Features#

  • Proximity-Based Responder Discovery: Uses haversine distance calculation to find active CFRs within configurable radius (default 2 km) of incident location, with presence staleness threshold of 15 minutes to ensure only responsive units are alerted.

  • Priority-Driven Alert Display: Responder mobile screen renders incident priority (P1 Immediately Life-Threatening through P4 Non-Urgent) with colour-coded accent indicators so responders instantly recognise criticality without reading detail.

  • Live ETA Countdown on Device: Responder sees continuously-updating estimated time of arrival in seconds, updating in real time as the responder moves and traffic conditions change, without requiring manual refresh or dispatcher radio traffic.

  • Two-Tap Acknowledge Response: Responder acknowledges in two taps (Acknowledge and Respond button, then confirmation), with offline-resilient handling so responders are never blocked by a temporarily unavailable backend.

  • Incident Context at a Glance: Responder sees incident type, exact latitude/longitude, responder's proximity to scene (e.g. "You are within 2 km of this incident"), and incident identifier, all necessary to assess job suitability before engaging.

  • Real-Time Acknowledgement Audit Trail: Every acknowledgement is recorded with responder user identifier, timestamp, and device state, creating a durable acknowledgement ledger for after-action review and compliance.

  • Automatic Primary Responder Rotation: When another CFR closer to the incident becomes available or acknowledges first, the dispatch system can rotate primary assignment and record the rotation as a first-class event on the canonical incident timeline.

  • Seamless Offline Resilience: Network failures during acknowledgement submission do not block the responder's navigation away from the alert screen; the responder progresses to the next task whilst the backend retries asynchronously.

Use Cases#

Community First Responder Cardiac Arrest#

A community first responder registers their location via the mobile app every time they move. An automated external defibrillator (AED) dispatch is triggered for a reported cardiac arrest. The system finds all CFRs within 2 km, pushes a critical priority (P1) alert to their devices, and the nearest responder sees a live ETA counting down to scene arrival. Upon acknowledgement, the dispatch system records the responder's acceptance, disables alerts for other CFRs in the same zone, and the incident timeline reflects the mobilisation.

Nearest-Unit Override and Rotation#

A secondary CFR closer to the incident acknowledges after the primary responder. The system detects the proximity advantage, rotates the primary assignment, and the incident timeline records the rotation event. The controller sees both responders on the command board and understands which unit is now closest and most appropriate.

Multi-Language Responder Team#

A fire brigade operates across a multi-language region. Critical alerts are pushed to responders with incident detail and ETA rendered in the responder's preferred language, set in their notification preferences.

Time-Zone and Shift-Aware Alerting#

CFRs have their active status tied to shift registration. When a responder goes off-shift, their presence record is deactivated, and they no longer receive alerts. At shift start, presence re-registers, and the responder is back in the proximity pool.

Integration#

The system delivers alerts through push notification to the responder mobile app. Incident location (latitude, longitude), incident type, and priority are supplied by the dispatch console or intelligent dispatch engine. The Responder Mobile app, built on Expo React Native, handles push notification receipt, deep-links the responder to the CFR Alert Screen, and renders alert details with live ETA sourced from the AVL and OSRM routing layer. Responder acknowledgement is sent back to the platform, which records it and updates the canonical incident timeline.

Proximity Search: A geospatial proximity service runs a haversine distance query against active responders, filtering for recent presence updates within the last 15 minutes. Results are ordered by ascending distance and returned as a ranked list of responders ready for alert dispatch.

Alert Dispatch: dispatch_cfr_alert() creates an alert record, finds nearby CFRs, and in live mode POSTs to the national Community First Responder Scheme (CFRS) API. In simulator mode (default), the alert is persisted locally and an immediate success response is returned. Each dispatch is audit-logged via log_interop_ingest() with standard="CFRS_DISPATCH", capturing responder count and incident detail for compliance.

Real-Time Acknowledgement: Responder Mobile sends an acknowledgement recording who responded and when. The acknowledgement is then reflected on the canonical incident timeline as a structured argus.dispatch.cfr_acknowledged event.

Live ETA Rendering: ETA is computed by the AVL and OSRM routing service (see AVL with Road-Graph Routing module). The responder mobile app subscribes to position and traffic updates and re-renders the ETA countdown in real time, with formatted output (e.g. "3m 45s").

Push Notification Channel: The mobile field application handles critical alert delivery with haptic feedback and PHI redaction for lock-screen presentation. Alert detail (full body) is stored in the notification data payload so the in-app handler (post-tap, post-authentication) can render full context.

Offline Resilience: Mobile acknowledgement handler catches network errors and treats HTTP 404 as success (endpoint not yet deployed), allowing responders to proceed without backend availability blocking their workflow.

Open Standards#

  • GraphQL (June 2018 specification): the platform API exposes all alert dispatch, acknowledgement, responder presence, and incident timeline operations through a typed GraphQL schema, enabling structured querying and mutation by the responder mobile app and dispatch console.
  • JSON Web Token (RFC 7519): every dispatch and acknowledgement request derives the acting user identity and tenant scope exclusively from a JWT, ensuring actor attribution is cryptographically bound and cannot be spoofed by the client payload.
  • ISO 8601 / RFC 3339 date-time format: all timestamps produced by the service (dispatch time, acknowledgement time, presence last-seen, ETA expiry) are serialised as ISO 8601 strings, ensuring interoperability with the canonical incident timeline and downstream audit consumers.
  • GeoJSON (RFC 7946): route geometry returned by the road-graph routing layer is encoded as a GeoJSON LineString, allowing responder mobile clients and mapping components to render the projected path using any standards-compliant mapping library.
  • WGS 84 geodetic datum (EPSG:4326): all responder presence coordinates, incident locations, and proximity-search haversine calculations operate on WGS 84 latitude/longitude pairs, consistent with GPS device output and standard geospatial interchange.
  • OSRM HTTP API (Open Source Routing Machine): live ETA computation uses the OSRM road-network routing API as the primary tier, with responses tagged by provider so downstream logic can distinguish road-graph ETAs from haversine fallback estimates.
  • Standard Webhooks v1 (HMAC-SHA-256 signing): outbound critical-alert notifications follow the Standard Webhooks wire format with HMAC-SHA-256 request signatures, allowing receiving endpoints to verify integrity and origin before processing dispatch events.
  • Expo Push Notification API (FCM / APNs transport): mobile push delivery to Android and iOS responder devices is routed through the Expo Push API, which internally uses Firebase Cloud Messaging and Apple Push Notification service as the respective platform transports.

Security and Compliance#

  • Organisation-Level Isolation: All queries filter by organisation, ensuring responder presence and alert data are segregated per tenant.

  • PHI Redaction on Lock Screen: Incident type, location, and priority may contain protected health information. Lock-screen notification banners redact sensitive body content to a generic placeholder (ARGUS_PHI_NOTIFICATION_REDACT=true, default), with full detail stored in encrypted notification data for authenticated in-app access.

  • Audit Trail: Every alert dispatch and acknowledgement is logged via log_interop_ingest() with user, organisation, timestamp, and responder count for regulatory compliance and after-action review.

  • Secure Push Channel: Mobile push delivery follows Standard Webhooks (HMAC SHA-256) signing pattern where applicable, so receivers can verify integrity and origin.

  • Position Data Retention: Responder location updates are persisted to the responder presence store with a 15-minute staleness threshold for presence lookup, balancing real-time accuracy with privacy (stale presence is not alerted and is eventually pruned per data retention policy).

Availability#

Available on Responder Mobile (Expo React Native, iOS and Android). Community First Responder Scheme integration requires DFB_CFR_ALERTING_MODE and DFB_CFR_ALERTING_ENDPOINT environment variables; when unset, the system operates in local simulator mode for development and testing.

Last Reviewed: 2026-05-07 Last Updated: 2026-05-07

Ready to Build?

Get started with our APIs or contact our integration team for support.