Emergency call (112) analysis & dispatcher decision support

In the first minute of a 112 call the dispatcher must recognise a time-critical condition such as cardiac arrest from a panicked, noisy, often non-native caller. Streaming speech recognition plus semantic and acoustic classifiers listen along, flag suspected out-of-hospital cardiac arrest (OHCA) or stroke, propose protocol questions and pre-fill the record. The dispatcher stays fully in charge; the goal is earlier recognition and earlier telephone CPR, not automated dispatch.

Problem & value

• Today: the call-taker (Leitstelle/PSAP) asks structured questions per a protocol, types the record by hand, and judges urgency by ear while listening and typing. Recognition of cardiac arrest on the phone is a known bottleneck; every minute without CPR lowers survival. Foreign-language callers need interpreter conferencing, which costs time.
• AI value: a second pair of ears that does not tire, earlier OHCA recognition, less typing, consistent protocol coverage, faster handling of non-native callers, and structured data for QA.
• Evidence (mixed, be honest): the Copenhagen EMS studies of the Danish vendor Corti showed that a machine-learning model could recognise OHCA in calls faster/more often than dispatchers in a retrospective analysis [1], but the randomised trial of live alerts found no significant improvement in dispatcher recognition [2]. Real-world benefit depends on workflow integration and alert design, not only on model accuracy.

Variants

• 112 emergency medical (Leitstelle): OHCA, stroke, respiratory distress; integrated or non-integrated Leitstellen (fire, rescue, medical).
• 116117 / non-emergency medical advice: lower urgency, more triage, overlaps CONV-010/CONV-021.
• Multilingual call handling: real-time transcript and translation for callers in other languages (see SPEECH-003).
• Record pre-fill and documentation only: lowest-risk subset (transcript, address and complaint extraction), without clinical alerts.
• Post-call QA and training: analysis of recorded calls for protocol compliance (see SPEECH-002).
• 911 / North America: same architecture with NENA i3 / NG911 and different protocol vendors.
• Police and fire 110/112 lines: policy-level only; no suspect profiling or caller identification, see risks.

How it works

1. telephony (SIP/RTP, PSAP call recording fork)
2. audio preprocessing (8 kHz telephony, noise suppression, VAD, channel split caller/call-taker)
3. streaming ASR (multilingual, language ID) + diarization
4. parallel analysis: text/semantic classifiers & LLM (conscious? breathing? chest pain? FAST signs?) acoustic classifiers (agonal breathing, background cues; SPEECH-009)
5. decision-support engine: alert + suggested question + keyword code, with confidence & evidence span
6. dispatcher UI (control-room system: CAD / Einsatzleitsystem) — accept, ignore, correct
7. pre-filled incident record, dispatcher confirms
8. logging of alerts vs. final dispatcher decision (audit, monitoring, retraining)

• Latency budget: partial transcripts within about a second; alerts must not distract. Alert fatigue and false positives are the main usability risk.
• Human-in-the-loop: the dispatcher decides on dispatch, priority and instructions. The system never dispatches resources or ends a call. The protocol system (e.g. structured emergency assessment) remains the primary tool; AI is advisory.
• Fail-safe: if ASR or the AI service is down, the call proceeds unchanged; no dependency in the call path.

Data preparation

The data is live call audio (8 to 16 kHz, noisy), caller location (AML, eCall), the dispatch protocol and incident records in the control-room system. Recordings sit in the call-recording system and archives, incident data in the dispatch system, protocols as PDFs or inside protocol software. Typical gaps are poor telephone audio, dialects and stressed speech, missing or inconsistent incident labels, recordings with restricted access, and no labelled outcome data such as confirmed cardiac arrest.

Steps: 1. Map data sources and access rights (PREP-001, PREP-002). 2. Clarify purpose and legal basis for reusing recordings (PREP-025). 3. Pseudonymise exports (PREP-022). 4. Build an evaluation set with experienced dispatchers and medical directors (PREP-018). 5. Harvest outcome labels from incident records (PREP-020).

Preparation is a large share, around 40 to 50 percent, because of legal clearance, noisy audio and expert labelling.

Implementation paths

Which path for whom

• public: Path A, because dispatch centres need certified, supported products integrated with the control-room system and high-risk duties are best carried with a vendor.
• enterprise: Path A, because private rescue and service operators face the same safety and certification demands and have no reason to build core call-handling software.
• developer: Path B, because vendors and integrators build on ASR and classifier APIs, with sensitive call audio processed only under strict EU hosting and AVV.

Path A — Buy (recommended)

• Specialised vendors: Corti (Denmark, EU) for live call decision support; Hexagon, Motorola Solutions (Vesta/CommandCentral), Axon (Carbyne), Intrado and Tyler/Zuercher for CAD/call-handling with AI add-ons, mostly US; German and European control-room suppliers such as Leitstellen system vendors (e.g. Eurofunk, Frequentis or regional ELS providers) add or partner for speech modules. Check current product status with your ELS vendor.
• Choose A because: public-safety procurement, MDR/AI Act conformity, 24/7 support and ELS integration rarely make sense to build in-house.
• Check: EU/on-premise or sovereign-cloud hosting, conformity evidence, languages and dialects, telephony and ELS integration, audit logs, and exit clauses.

Path B — Build on cloud APIs

• Streaming ASR from Azure AI Speech, Google Cloud Speech-to-Text, AWS Transcribe (EU regions) or EU providers (e.g. Speechmatics UK, Deepgram EU endpoints). General LLMs for extraction in an EU region. Cloud use by a public authority needs a clear legal basis, sovereignty review and usually a private or government cloud. Fits pilots such as pre-fill and translation, less so critical alerts.

Path C — Self-host (open source)

• ASR: Whisper large-v3 / turbo (OpenAI, MIT) [4] via faster-whisper or WhisperX; NVIDIA Parakeet/Canary; Vosk or sherpa-onnx for lightweight streaming; Silero VAD; pyannote for diarization.
• Classifiers: fine-tuned encoder (BERT-class) for symptom intents; open LLM (Mistral, Qwen, Llama class) served via vLLM for extraction; audio classifier (e.g. PANNs/AST-style) for breathing cues.
• Hardware: HW3 for several concurrent streams with an LLM; HW2 suffices for ASR plus small models in a small Leitstelle. Run in the Leitstelle data centre, redundant, with no outbound traffic.
• Effort: high; needs ML, telephony and clinical safety teams.

Path D — Custom training

Important here. Telephone-quality, stressed, dialectal German (and regional languages) with medical vocabulary is poorly covered by public ASR corpora. Fine-tune ASR and OHCA classifiers on the centre's own recordings (with legal basis, pseudonymisation and ethics approval), validated prospectively against dispatcher and registry outcomes. Needs thousands of labelled calls, including true negatives, and multi-centre validation to avoid local overfitting.

State of the art (2026)

• Streaming ASR on noisy 8 kHz audio has improved with large multilingual models, yet error rates rise with accent, stress, overlapping speech and medical terms or addresses; place names and house numbers remain error-prone, so location comes from AML/GPS, not ASR.
• OHCA detection from semantic and acoustic cues is the best-studied function [1][2]; benefit in controlled trials was less than retrospective results suggested. Open research: calibrated alerts, explanation of why an alert fired, and cross-language generalisation.
• LLM-based record pre-fill and summaries are in pilots; hallucination control and span-level evidence ("this field came from this utterance") are expected.
• Limits: bias against accents, dialects and speech impairments; false negatives creating automation bias; silent calls and non-verbal callers; adversarial or prank calls; model drift with protocol changes.

Shared resources & combinations

• Same stack (asr + diarization + streaming): SPEECH-001/002/004 transcription and analytics, SPEECH-020 mission-critical radio transcription (same Leitstelle), SPEECH-003 translation.
• Acoustic cues: SPEECH-009 audio event detection.
• Neighbours: CONV-021 (call triage assistant, caller-facing automation), CONV-007 agent assist, CONV-010 symptom triage, OPT-029 ambulance deployment planning downstream.

Effort, cost & KPIs

• Path A: 6-18 months from tender to production incl. ELS integration and shadow-mode evaluation; licence per workplace/call volume.
• Path B/C: 12-24 months with clinical validation; ongoing MLOps and safety management.
• KPIs: time to OHCA recognition, time to first compression instruction, telephone-CPR rate, alert precision/recall and override rate, alert fatigue, record completion time, ASR word error rate on real calls (also per language/dialect), 30-day survival (long-term, with registry).

People & change

Involve management and the department lead (control-centre head, medical director) from the start, since this is a safety-critical, high-risk setting. Dispatchers are the end users and must co-design alerts and the interface. IT security, the DPO and legal or compliance are needed early: call audio is highly sensitive personal data, so a DPIA and an AVV are required.

Works council: yes. A live system that listens to calls and produces quality data is objectively suited to monitor employees' performance (§87(1) no. 6 BetrVG), so a works agreement is needed; the staff council (Personalrat) under BPersVG or state law applies in public bodies. Inform it in good time under §90(1) no. 3 and consider an AI expert under §80(3) (GUIDE-004).

AI literacy: support dispatchers with training on alert limits, false alarms and automation bias, in line with AI Act Art. 4. Run a pilot on a few shifts in shadow mode first, with a clear go/no-go. The dispatcher always decides; alerts are suggestions and never replace the protocol. Typical concerns are surveillance and deskilling; address them with a written ban on individual performance ranking and an open feedback channel.

Guides: GUIDE-004, GUIDE-005, GUIDE-009.

Risks, regulation & compliance

• EU AI Act: high risk, Annex III 5(d): AI systems for evaluating and classifying emergency calls and dispatching or establishing priority in emergency first-response services, including emergency healthcare patient triage [3]. Obligations: risk management, data governance, logging, human oversight, accuracy and robustness, deployer FRIA and registration for public bodies. A clinical alert function may also be medical device software under the MDR (Class IIa or higher is common for decision support), so check both regimes.
• Art. 5 flag: emotion recognition is prohibited in workplace and education, so do not use call-taker emotion or stress analysis for monitoring staff. Do not infer callers' emotions, origin or identity for enforcement purposes; voice biometrics of callers is out of scope (see SPEECH-010).
• GDPR: emergency calls contain health data (Art. 9) and often third-party data. Legal basis is typically a public task (Art. 6(1)(e), 9(2)(g)/(h)) and national emergency or health-service laws; DPIA mandatory; retention limits for recordings; strict access control; no use of call audio to train vendor models without legal basis.
• Telecom and critical infrastructure: EECC / European emergency number rules (112), NIS2 for availability, and data-sovereignty requirements for public-sector hosting.
• Mitigations: shadow mode first, advisory-only alerts, bias testing across languages and dialects, fallback to normal operation, incident reporting, and dispatcher training on automation bias.

Getting started

1. Define the use scope: pre-fill and translation first; clinical alerts only after shadow mode.
2. Run a DPIA and AI Act / MDR classification with data protection officer and legal counsel.
3. Record a baseline: time to recognition, telephone-CPR rate, record completion time.
4. Run a shadow-mode pilot (alerts logged, not shown) on historic and live calls; measure per language and dialect.
5. Launch advisory alerts with a small dispatcher group, monitor override rates and recalibrate.

Sources

1. Blomberg SN et al. — Machine learning as a supportive tool to recognize cardiac arrest in emergency calls, Resuscitation 2019 — https://pubmed.ncbi.nlm.nih.gov/?term=Blomberg+machine+learning+cardiac+arrest+emergency+calls+Resuscitation+2019
2. Blomberg SN et al. — Effect of Machine Learning on Dispatcher Recognition of Out-of-Hospital Cardiac Arrest During Calls to Emergency Medical Services: A Randomized Clinical Trial, JAMA Network Open 2021 — https://pubmed.ncbi.nlm.nih.gov/?term=Blomberg+dispatcher+recognition+cardiac+arrest+machine+learning+randomized+JAMA+Netw+Open+2021
3. Regulation (EU) 2024/1689 (AI Act), Annex III point 5(d) and Art. 5 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. OpenAI Whisper — https://github.com/openai/whisper
5. EENA — European Emergency Number Association, publications on AI in emergency communications — https://eena.org
6. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
7. Corti — https://www.corti.ai