Katalog / Sprach- und Audio-KI / SPEECH-016

Notruf-112-Analyse & Entscheidungsunterstützung für Disponenten

Live-Spracherkennung und Klassifikatoren hören bei Notrufen über 112/116117 mit, warnen Disponenten bei Verdacht auf Herz-Kreislauf-Stillstand oder Schlaganfall, schlagen Protokollfragen vor und füllen den Einsatzdatensatz vor, wobei stets der Disponent entscheidet.

In der ersten Minute eines 112-Anrufs muss der Disponent einen zeitkritischen Zustand wie einen Herz-Kreislauf-Stillstand bei einem panischen, verrauschten und oft nicht muttersprachlichen Anrufer erkennen. Streaming-Spracherkennung plus semantische und akustische Klassifikatoren hören mit, melden den Verdacht auf einen außerklinischen Herz-Kreislauf-Stillstand (OHCA) oder Schlaganfall, schlagen Protokollfragen vor und füllen den Datensatz vor. Der Disponent behält die volle Verantwortung; Ziel ist eine frühere Erkennung und eine frühere Telefonreanimation, nicht eine automatisierte Disposition.

Problem & Nutzen

  • Heute: Der Notrufabfragende (Leitstelle/PSAP) stellt strukturierte Fragen nach einem Protokoll, tippt den Datensatz von Hand und beurteilt die Dringlichkeit nach Gehör, während er zuhört und tippt. Die Erkennung eines Herz-Kreislauf-Stillstands am Telefon ist ein bekannter Engpass; jede Minute ohne Reanimation senkt die Überlebenschance. Fremdsprachige Anrufer erfordern eine Dolmetscher-Zuschaltung, was Zeit kostet.
  • KI-Nutzen: ein zweites Paar Ohren, das nicht ermüdet, frühere OHCA-Erkennung, weniger Tipparbeit, einheitliche Abdeckung des Protokolls, schnellere Bearbeitung von nicht muttersprachlichen Anrufern und strukturierte Daten für die Qualitätssicherung.
  • Belegbarkeit (gemischt, ehrlich gesagt): Die Kopenhagener Rettungsdienst-Studien zum dänischen Anbieter Corti zeigten, dass ein Machine-Learning-Modell in einer retrospektiven Analyse OHCA in Anrufen schneller bzw. häufiger erkennen konnte als Disponenten [1], die randomisierte Studie mit Live-Warnungen fand jedoch keine signifikante Verbesserung bei der Erkennung durch die Disponenten [2]. Der Nutzen in der Praxis hängt von der Einbindung in den Arbeitsablauf und vom Warnungsdesign ab, nicht nur von der Modellgenauigkeit.

Varianten

  • 112 Notfallmedizin (Leitstelle): OHCA, Schlaganfall, Atemnot; integrierte oder nicht integrierte Leitstellen (Feuerwehr, Rettungsdienst, Medizin).
  • 116117 / ärztlicher Bereitschaftsdienst: geringere Dringlichkeit, mehr Triage, überschneidet sich mit CONV-010/CONV-021.
  • Mehrsprachige Anrufbearbeitung: Echtzeit-Transkript und Übersetzung für Anrufer in anderen Sprachen (siehe SPEECH-003).
  • Nur Datensatz-Vorausfüllung und Dokumentation: die risikoärmste Teilmenge (Transkript, Extraktion von Adresse und Beschwerde), ohne klinische Warnungen.
  • Qualitätssicherung und Schulung nach dem Anruf: Analyse aufgezeichneter Anrufe auf Protokolltreue (siehe SPEECH-002).
  • 911 / Nordamerika: gleiche Architektur mit NENA i3 / NG911 und anderen Protokollanbietern.
  • Polizei- und Feuerwehrleitungen 110/112: nur auf Grundsatzebene; keine Verdächtigenprofile und keine Identifizierung von Anrufern, siehe Risiken.

So funktioniert es

  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)
  • Latenzbudget: Teiltranskripte innerhalb von etwa einer Sekunde; Warnungen dürfen nicht ablenken. Warnmüdigkeit und Fehlalarme sind das größte Risiko für die Bedienbarkeit.
  • Mensch-in-der-Schleife (Human-in-the-Loop): Der Disponent entscheidet über Alarmierung, Priorität und Anweisungen. Das System alarmiert nie Einsatzmittel und beendet nie einen Anruf. Das Protokollsystem (z. B. strukturierte Notrufabfrage) bleibt das primäre Werkzeug; die KI ist beratend.
  • Ausfallsicherheit: Fällt die ASR oder der KI-Dienst aus, läuft der Anruf unverändert weiter; es gibt keine Abhängigkeit im Gesprächspfad.

Datenaufbereitung

Die Daten sind Live-Anrufaudio (8 bis 16 kHz, verrauscht), der Standort des Anrufers (AML, eCall), das Abfrageprotokoll und Einsatzdatensätze im Leitstellensystem. Aufzeichnungen liegen im Aufzeichnungssystem und in Archiven, Einsatzdaten im Einsatzleitsystem, Protokolle als PDF oder innerhalb der Protokollsoftware. Typische Lücken sind schlechte Telefonaudioqualität, Dialekte und gestresste Sprache, fehlende oder uneinheitliche Einsatzlabels, Aufzeichnungen mit beschränktem Zugriff und keine gelabelten Ergebnisdaten wie ein bestätigter Herz-Kreislauf-Stillstand.

Schritte: 1. Datenquellen und Zugriffsrechte erfassen (PREP-001, PREP-002). 2. Zweck und Rechtsgrundlage für die Wiederverwendung von Aufzeichnungen klären (PREP-025). 3. Exporte pseudonymisieren (PREP-022). 4. Mit erfahrenen Disponenten und Ärztlichen Leitern einen Evaluationsdatensatz aufbauen (PREP-018). 5. Ergebnislabels aus Einsatzdatensätzen gewinnen (PREP-020).

Die Aufbereitung macht einen großen Anteil aus, rund 40 bis 50 Prozent, wegen rechtlicher Klärung, verrauschten Audios und Expertenlabelns.

Umsetzungswege

Welcher Weg für wen

  • public: Weg A, weil Leitstellen zertifizierte, unterstützte Produkte brauchen, die in das Leitstellensystem integriert sind, und Pflichten mit hohem Risiko am besten gemeinsam mit einem Anbieter getragen werden.
  • enterprise: Weg A, weil private Rettungs- und Dienstleistungsbetreiber dieselben Sicherheits- und Zertifizierungsanforderungen haben und keinen Grund, Kernsoftware zur Anrufbearbeitung selbst zu bauen.
  • developer: Weg B, weil Anbieter und Integratoren auf ASR- und Klassifikator-APIs aufbauen, wobei sensibles Anrufaudio nur unter strenger EU-Datenhaltung und mit AVV verarbeitet wird.

Weg A — Kaufen (Standardsoftware)

  • Empfohlen.
  • Spezialisierte Anbieter: Corti (Dänemark, EU) für Live-Entscheidungsunterstützung bei Anrufen; Hexagon, Motorola Solutions (Vesta/CommandCentral), Axon (Carbyne), Intrado und Tyler/Zuercher für CAD/Anrufbearbeitung mit KI-Erweiterungen, überwiegend aus den USA; deutsche und europäische Leitstellenlieferanten wie Anbieter von Leitstellen- systemen (z. B. Eurofunk, Frequentis oder regionale ELS-Anbieter) ergänzen Sprachmodule oder kooperieren dafür. Prüfen Sie den aktuellen Produktstatus bei Ihrem ELS-Anbieter.
  • A wählen, weil: Vergabe im Bereich der öffentlichen Sicherheit, MDR-/KI-Verordnungs-Konformität, 24/7-Support und ELS- Integration sich selten sinnvoll im eigenen Haus aufbauen lassen.
  • Prüfen: Hosting in der EU/On-Premises oder in einer Souveränen Cloud, Konformitätsnachweise, Sprachen und Dialekte, Telefonie- und ELS-Integration, Audit-Protokolle und Ausstiegsklauseln.

Weg B — Auf Cloud-KI-Diensten aufbauen

  • Streaming-ASR von Azure AI Speech, Google Cloud Speech-to-Text, AWS Transcribe (EU-Regionen) oder EU-Anbietern (z. B. Speechmatics UK, Deepgram mit EU-Endpunkten). Allgemeine LLMs zur Extraktion in einer EU- Region. Die Cloud-Nutzung durch eine Behörde braucht eine klare Rechtsgrundlage, eine Souveränitätsprüfung und meist eine private oder Behörden-Cloud. Geeignet für Piloten wie Vorausfüllung und Übersetzung, weniger für kritische Warnungen.

Weg C — Selbst betreiben (Open Source)

  • ASR: Whisper large-v3 / turbo (OpenAI, MIT) [4] über faster-whisper oder WhisperX; NVIDIA Parakeet/Canary; Vosk oder sherpa-onnx für schlankes Streaming; Silero VAD; pyannote für die Sprechertrennung.
  • Klassifikatoren: feingetunter Encoder (BERT-Klasse) für Symptom-Intents; offenes LLM (Mistral, Qwen, Llama-Klasse), bereitgestellt über vLLM, zur Extraktion; Audioklassifikator (z. B. im Stil von PANNs/AST) für Atemhinweise.
  • Hardware: HW3 für mehrere gleichzeitige Streams mit einem LLM; HW2 genügt für ASR plus kleine Modelle in einer kleinen Leitstelle. Betrieb im Rechenzentrum der Leitstelle, redundant, ohne ausgehenden Datenverkehr.
  • Aufwand: hoch; es braucht ML-, Telefonie- und klinische Sicherheitsteams.

Weg D — Eigenes Training

Hier wichtig. Deutsch in Telefonqualität, gestresst und dialektal gefärbt (und regionale Sprachen) mit medizinischem Vokabular ist in öffentlichen ASR-Korpora schlecht abgedeckt. Feintunen Sie ASR und OHCA-Klassifikatoren mit den eigenen Aufzeichnungen der Leitstelle (mit Rechtsgrundlage, Pseudonymisierung und Ethikvotum), prospektiv validiert gegen die Ergebnisse der Disponenten und des Registers. Es braucht tausende gelabelte Anrufe, einschließlich echter Negativbeispiele, und eine Validierung an mehreren Standorten, um lokale Überanpassung zu vermeiden.

Stand der Technik (2026)

  • Streaming-ASR auf verrauschtem 8-kHz-Audio hat sich mit großen mehrsprachigen Modellen verbessert, doch die Fehlerraten steigen bei Akzent, Stress, überlappender Sprache sowie medizinischen Begriffen oder Adressen; Ortsnamen und Haus- nummern bleiben fehleranfällig, daher kommt der Standort aus AML/GPS, nicht aus der ASR.
  • OHCA-Erkennung anhand semantischer und akustischer Hinweise ist die am besten untersuchte Funktion [1][2]; der Nutzen in kontrollierten Studien war geringer, als retrospektive Ergebnisse nahelegten. Offene Forschungsfragen: kalibrierte Warnungen, Erklärung, warum eine Warnung ausgelöst wurde, und sprachübergreifende Generalisierung.
  • LLM-basierte Datensatz-Vorausfüllung und Zusammenfassungen sind in Pilotphasen; Kontrolle von Halluzinationen und Belege auf Textstellenebene („dieses Feld stammt aus dieser Äußerung") werden erwartet.
  • Grenzen: Verzerrung gegenüber Akzenten, Dialekten und Sprachbehinderungen; Falsch-Negative, die einen Automatisierungs- Bias erzeugen; stille Anrufe und nonverbale Anrufer; Angriffe oder Scherzanrufe; Modelldrift bei Protokolländerungen.

Gemeinsame Bausteine & Kombinationen

  • Gleicher Stack (asr + diarization + streaming): SPEECH-001/002/004 Transkription und Analysen, SPEECH-020 Transkription von Einsatzfunk (dieselbe Leitstelle), SPEECH-003 Übersetzung.
  • Akustische Hinweise: SPEECH-009 Erkennung von Audioereignissen.
  • Nachbarn: CONV-021 (Assistent zur Anruf-Triage, Automatisierung auf Anruferseite), CONV-007 Agentenassistenz, CONV-010 Symptom-Triage, OPT-029 Einsatzplanung für Rettungswagen nachgelagert.

Aufwand, Kosten & Kennzahlen

  • Weg A: 6-18 Monate von der Ausschreibung bis zum Produktivbetrieb einkl. ELS-Integration und Auswertung im Schattenmodus; Lizenz je Arbeitsplatz/Anrufvolumen.
  • Weg B/C: 12-24 Monate mit klinischer Validierung; laufender MLOps- und Sicherheitsbetrieb.
  • Kennzahlen: Zeit bis zur OHCA-Erkennung, Zeit bis zur ersten Kompressionsanweisung, Rate der Telefonreanimation, Präzision/Trefferquote der Warnungen und Übersteuerungsrate, Warnmüdigkeit, Zeit bis zum vollständigen Datensatz, ASR-Wortfehlerrate bei echten Anrufen (auch je Sprache/Dialekt), 30-Tage-Überleben (langfristig, mit Register).

Menschen & Veränderung

Binden Sie die Geschäftsleitung und die Fachbereichsleitung (Leitstellenleiter, Ärztlicher Leiter) von Anfang an ein, da es sich um ein sicherheitskritisches Umfeld mit hohem Risiko handelt. Disponenten sind die Anwender und müssen Warnungen und Oberfläche mitgestalten. IT-Sicherheit, Datenschutzbeauftragte(r) sowie Recht oder Compliance werden früh gebraucht: Anrufaudio besteht aus hochsensiblen personenbezogenen Daten, daher sind eine DSFA und ein AVV erforderlich.

Betriebsrat: ja. Ein Live-System, das Anrufe mithört und Qualitätsdaten erzeugt, ist objektiv geeignet, die Leistung von Beschäftigten zu überwachen (§ 87 Abs. 1 Nr. 6 BetrVG), daher ist eine Betriebsvereinbarung nötig; in öffentlichen Stellen gilt der Personalrat nach BPersVG oder Landesrecht. Informieren Sie ihn rechtzeitig nach § 90 Abs. 1 Nr. 3 und ziehen Sie einen KI-Sachverständigen nach § 80 Abs. 3 in Betracht (GUIDE-004).

KI-Kompetenz: Unterstützen Sie Disponenten mit Schulungen zu den Grenzen der Warnungen, zu Fehlalarmen und zum Automatisierungs-Bias, gemäß Art. 4 der KI-Verordnung (AI Act). Führen Sie zuerst einen Pilot an wenigen Schichten im Schattenmodus durch, mit einer klaren Go/No-go-Entscheidung. Der Disponent entscheidet immer; Warnungen sind Vorschläge und ersetzen nie das Protokoll. Typische Sorgen sind Überwachung und Kompetenzverlust; begegnen Sie ihnen mit einem schriftlichen Verbot individueller Leistungsrankings und einem offenen Feedbackkanal.

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

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): hohes Risiko, Anhang III Nr. 5 Buchst. d: KI-Systeme zur Bewertung und Klassifizierung von Notrufen und zur Entsendung oder Priorisierung von Ersthelfer-Notfalldiensten, einschließlich der Triage von Patienten in der Notfall- medizin [3]. Pflichten: Risikomanagement, Daten-Governance, Protokollierung, menschliche Aufsicht, Genauigkeit und Robustheit, Grundrechte-Folgenabschätzung (FRIA) des Betreibers und Registrierung für öffentliche Stellen. Eine klinische Warnfunktion kann zudem Medizinprodukte-Software nach der MDR sein (Klasse IIa oder höher ist bei Entscheidungsunterstützung üblich); prüfen Sie daher beide Regelwerke.
  • Hinweis zu Art. 5: Emotionserkennung ist am Arbeitsplatz und in der Ausbildung verboten, nutzen Sie daher keine Emotions- oder Stressanalyse der Notrufabfragenden zur Überwachung von Beschäftigten. Schließen Sie nicht auf Emotionen, Herkunft oder Identität von Anrufern für Zwecke der Rechtsdurchsetzung; Stimmbiometrie von Anrufern ist nicht Gegenstand (siehe SPEECH-010).
  • DSGVO: Notrufe enthalten Gesundheitsdaten (Art. 9) und oft Daten Dritter. Die Rechtsgrundlage ist typischerweise eine öffentliche Aufgabe (Art. 6 Abs. 1 Buchst. e, Art. 9 Abs. 2 Buchst. g/h) und nationale Rettungsdienst- oder Gesundheitsgesetze; DSFA zwingend; Speicherfristen für Aufzeichnungen; strenge Zugriffskontrolle; keine Nutzung von Anrufaudio zum Training von Anbietermodellen ohne Rechtsgrundlage.
  • Telekommunikation und kritische Infrastruktur: EECC / europäische Regeln zur Notrufnummer (112), NIS2 für die Verfügbarkeit und Anforderungen an die Datensouveränität für das Hosting im öffentlichen Sektor.
  • Gegenmaßnahmen: zuerst Schattenmodus, nur beratende Warnungen, Bias-Tests über Sprachen und Dialekte hinweg, Rückfall auf den Normalbetrieb, Vorfallsmeldung und Schulung der Disponenten zum Automatisierungs-Bias.

Erste Schritte

  1. Legen Sie den Einsatzumfang fest: zuerst Vorausfüllung und Übersetzung; klinische Warnungen erst nach dem Schattenmodus.
  2. Führen Sie mit der(dem) Datenschutzbeauftragten und der Rechtsberatung eine DSFA und die Einstufung nach KI-Verordnung (AI Act) / MDR durch.
  3. Erfassen Sie eine Ausgangsbasis: Zeit bis zur Erkennung, Rate der Telefonreanimation, Zeit bis zum vollständigen Datensatz.
  4. Führen Sie einen Pilot im Schattenmodus durch (Warnungen werden protokolliert, nicht angezeigt), mit historischen und Live-Anrufen; messen Sie je Sprache und Dialekt.
  5. Starten Sie beratende Warnungen mit einer kleinen Disponentengruppe, überwachen Sie die Übersteuerungsraten und kalibrieren Sie nach.

Quellen

  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