Overview#
A real-time advisory partner that listens to the live emergency call alongside the call-taker, transcribes it securely within your tenancy, and surfaces next-best-question prompts, red-flag symptom flags, and step-by-step coaching scripts so the call-taker is never alone on a complex call.
When a call-taker is handling a complex emergency, for example a cardiac arrest where a bystander is unable to perform CPR, the Partner times its prompts to the conversation and pushes verbatim coaching script suggestions directly into the active-call screen rather than forcing the call-taker to switch tools. Every suggestion sits beside the protocol engine rather than replacing it, and every suggestion is logged with the model identifier, model version, confidence score, and the surrounding call context so calls can be reviewed for advisory behaviour after the fact.
Key Features#
-
Live Call Transcription In-Tenancy: The active emergency call is streamed to a speech-to-text provider with caller consent, with tenant isolation enforced throughout, so the Partner reasons over actual caller words rather than dispatcher notes alone.
-
Next-Best-Question Prompts: The Partner surfaces the next clinical or situational question the call-taker should ask, scoped to the chief complaint and the conversation so far.
-
Red-Flag Symptom Detection: Clinical and situational red flags heard in the call, for example agonal breathing, choking sounds, or signs of imminent childbirth, are flagged in real time so the call-taker does not have to catch every cue alone.
-
Coaching Scripts and Algorithms: Verbatim hands-only CPR coaching, choking algorithm steps, and childbirth talk-through scripts are presented for the call-taker to read directly to the caller, drawn from JRCALC 2024 clinical practice guidelines and tenant-specific standard operating procedures.
-
AMPDS-Aligned Priority Suggestions: The Partner produces ranked chief-complaint candidates and AMPDS determinant code suggestions from the rolling call transcript, giving the call-taker a structured starting point before they confirm the priority.
-
Supervisor Escalation Suggestions: When situations typically warrant a supervisor or specialist, mass-casualty events, hostage incidents, child abductions, or on-scene violence, the Partner suggests escalation rather than acting autonomously.
-
Protocol-Engine Coexistence: The Partner is layered beside, never on top of, the existing PSAP protocol engine, so authoritative dispatch logic and certified clinical protocols remain in their certified place.
-
Per-Suggestion Audit: Every suggestion is recorded with the model identifier, model version, confidence score, and the surrounding call context for clinical and operational review.
-
Canonical Incident Timeline Binding: Every Partner suggestion is bound to the active call session and appears on the unified incident timeline so reviewers see Partner activity alongside dispatcher actions.
Use Cases#
Emergency Medical Dispatch#
-
Cardiac Arrest with Untrained Bystander: The caller reports a collapse and the bystander cannot perform CPR. The Partner surfaces the hands-only CPR coaching script in cadence with the conversation so the call-taker can guide the bystander without breaking away from the call.
-
Choking Incident: The Partner recognises the situation from the transcript and surfaces the choking algorithm and back-blow / abdominal-thrust script in the correct sequence.
-
Imminent Childbirth: The Partner cues the call-taker through a prepared childbirth talk-through script and prompts critical assessment questions as the situation develops.
High-Complexity and Supervisor-Level Events#
-
Possible Mass-Casualty or Violent Incident: The Partner suggests supervisor escalation and flags high-risk phrases for the watch-commander's attention.
-
Multilingual Distress Call: The Partner uses the translated transcript stream from the multilingual call-taking pipeline so it can reason and prompt even when the call is being interpreted live.
Quality Assurance and Governance#
- Call Review and Advisory Behaviour Audit: QA reviewers can audit the full Partner history for any call alongside the dispatcher's actual decisions, including which suggestions were accepted, ignored, or overridden. Every suggestion record carries model identifier, model version, and confidence score.
Integration#
Organisations integrate the AI Dispatcher Partner through the same platform APIs used by the broader PSAP module.
-
REST and GraphQL: Suggestion output is available over the platform REST API and GraphQL layer in a JSON-normalised format that maps naturally to existing CAD and quality-assurance tooling.
-
WebSocket Push: Real-time suggestions are delivered to the call-taker workstation over a secure WebSocket channel scoped to the live call session, so the drawer updates without polling.
-
Unified Incident Timeline: Every suggestion is emitted as a CloudEvents 1.0 envelope and written to the shared incident timeline, making it available to any downstream consumer that subscribes to the standard event stream.
-
Clinical Knowledge Retrieval: Coaching scripts and priority suggestions are retrieved from a tenant-aware clinical knowledge base that blends JRCALC 2024 national guidelines with tenant-specific SOPs, returned at suggestion time rather than pre-loaded, so guidance is always current.
-
OAuth 2.0 and JWT Authorisation: All API access is authorised using OAuth 2.0 bearer tokens scoped to the tenant, consistent with the platform-wide identity model. Call-taker workstation sessions bind to the token principal so audit records carry the authenticated actor.
-
Normalised Suggestion Model: The suggestion payload is a stable, versioned JSON schema regardless of which reasoning pipeline produced it, heuristic-only, model-enhanced, or multilingual, so call-taker UI and downstream consumers need only one integration path.
-
Webhooks: Partner suggestion notifications can be fanned out to external systems using the Standard Webhooks specification with HMAC-SHA256 signatures for receiver verification.
Open Standards#
-
NENA-STA-006.3 (NG9-1-1 Core Services): the Partner is deployed within an NG9-1-1 architecture and its call-session binding aligns with the NENA functional element model for call-handling services.
-
NENA-STA-012 (Additional Data): call context passed to the reasoning layer follows the NENA-STA-012 additional data block structure, including subscriber, service, and location blocks.
-
NENA-STA-010.3 (i3 Architecture): the platform's underlying voice routing conforms to the NENA i3 emergency services IP network architecture; the Partner attaches to the same call session that i3 manages.
-
NENA EIDO (Emergency Incident Data Object): incident records and unit status updates that the Partner references use the NENA EIDO vocabulary, enabling interoperability with EIDO-compliant CAD systems.
-
RFC 7865 / RFC 7866 (SIPRec): where SIPREC-based call recording is in use, the Partner can consume the SIPREC metadata stream to bind its suggestions to the canonical call session without a separate audio path.
-
RFC 7852 (Additional Data over HTTP): additional caller and device data delivered to the platform follows the RFC 7852 block structure used throughout the i3 stack.
-
RFC 5222 (LoST): location-to-service-translation queries that inform routing decisions feeding the Partner use the IETF LoST protocol.
-
AMPDS (Advanced Medical Priority Dispatch System): chief-complaint and priority-determinant suggestions use the AMPDS protocol numbering and determinant-code taxonomy so outputs align with the coding scheme already in use at EMD-certified centres.
-
JRCALC Clinical Practice Guidelines (UK, 2024 edition): CPR, choking, and childbirth coaching scripts are grounded in the JRCALC 2024 national clinical guidelines used by UK emergency services.
-
ITU-T T.140 / RFC 4103: real-time text sessions on the same call-session layer use T.140 semantics, allowing the Partner to operate alongside RTT-capable callers without a separate integration path.
-
CloudEvents 1.0 (CNCF): every Partner suggestion event is wrapped in a CloudEvents 1.0 envelope so downstream consumers can subscribe using a standard, vendor-neutral event format.
-
AsyncAPI 2.6: the Partner suggestion channel is documented as an AsyncAPI contract so partner systems can generate typed consumers from the published specification.
-
Standard Webhooks (HMAC-SHA256): outbound Partner notifications use the Standard Webhooks specification for signed, verifiable delivery to external systems.
-
W3C WCAG 2.2: the call-taker suggestion drawer meets WCAG 2.2 Level AA contrast, focus management, and screen-reader requirements for accessible emergency workstations.
-
OAuth 2.0 / JWT: all platform API access, including the Partner suggestion endpoints, is authorised using OAuth 2.0 bearer tokens in JSON Web Token format.
-
HTTPS / TLS 1.3: all Partner traffic, transcript streams, suggestion delivery, and webhook notifications, is carried over TLS 1.3.
Security and Compliance#
The AI Dispatcher Partner is advisory only. Final dispatch and clinical decisions remain with the human call-taker at all times. The certified protocol engine retains full authority; the Partner may only suggest, never act.
Every suggestion record carries the model identifier, model version, confidence score, and the full call context that produced it. This provides a complete, time-stamped audit trail for clinical review, coroner inquiries, and operational quality assurance.
Transcription is processed within the tenant boundary. Audio is not shared across tenants, is not retained beyond the session unless explicitly configured by the tenant, and is subject to the tenant's data retention and deletion policies.
Access to Partner suggestions and audit records is governed by the platform role model, ensuring that only authorised supervisors and QA reviewers can access call-level detail.
Last Reviewed: 2026-05-05 / Last Updated: 2026-05-05