Service-Hotline für Medizingeräte KI-gestützt dokumentieren

Das echte Ausmaß des Problems

Medizintechnik-Hersteller betreiben ihre Service-Hotline als vorderste Linie des Post-Market Surveillance-Systems — und damit als direkte Datenquelle für die Post-Market Surveillance-Berichte, die MDR verlangt. Jeder Anruf ist potenziell regulatorisch relevant: Laut Artikel 87 der EU-Medizinprodukteverordnung (MDR) muss jeder Hersteller schwerwiegende Vorkommnisse und Sicherheitskorrekturmaßnahmen im Feld unverzüglich melden — im Todesfall innerhalb von 10 Tagen, bei schwerwiegenden Gesundheitsverschlechterungen innerhalb von 15 Tagen, bei einer ernsthaften Bedrohung der öffentlichen Gesundheit innerhalb von 2 Tagen.

Das Problem: Die Fähigkeit, diese Fristen einzuhalten, hängt davon ab, dass der Auslöser überhaupt erkannt wird. Und das ist bei unstrukturierter Gesprächsdokumentation zuverlässig nicht der Fall.

Typische Realität in Medizintechnik-Unternehmen mit manueller Hotline-Dokumentation:

• Uneinheitliches Format: Jede Person dokumentiert nach eigenem Schema — eine schreibt „E47-Fehler”, die nächste „Fehlercode 47”, die dritte „Code E47 nach Update”. Drei verschiedene Einträge für dasselbe Problem, nicht aggregierbar.
• Relevanz-Blindheit im Gespräch: Ein Anrufer sagt „Der Patient hatte kurz Schmerzen, aber das Gerät funktioniert wieder”. Hotline-Mitarbeitende sind selten geschult, diese Formulierung als mögliches Vigilanz-Signal zu erkennen.
• Nachträgliche Rekonstruktion ist teuer: Wenn der Vigilanzbeauftragte einen Trend vermutet, muss er historische Tickets manuell durchforsten. Für 200 Anrufe pro Monat ist das Tagesarbeit — und die Tendenz ist lückenhaft.

Einer Analyse des Johner Instituts zufolge sind unzureichende Vigilanz-Prozesse einer der häufigsten Mangelbefunde bei MDR-Audits durch Benannte Stellen und Behörden — ein direktes Signal, dass die Lücke zwischen tatsächlichen Service-Ereignissen und dokumentierter Vigilanz systematisch unterschätzt wird (Johner Institut, Blog, Vigilanzsystem für Medizinprodukte, 2024).

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Nachbearbeitung meint: Prüfung und Freigabe des KI-generierten Eintrags durch Hotline-Mitarbeitende.

Die Einsparung bei der Dokumentationszeit ist real, aber nicht der Hauptnutzen. Der Hauptnutzen ist die systematische Erkennung von Mustern und Vigilanz-Signalen — etwas, das manuell schlicht nicht zuverlässig möglich ist.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) 10–15 Minuten weniger Dokumentationsaufwand je Anruf sind real messbar. Bei einem Hotline-Team, das täglich 20–40 Gespräche verarbeitet, sind das 3–10 Personenstunden täglich. Stärker als viele Dokumentationsanwendungen in dieser Kategorie — aber kein Extremwert, weil die menschliche Nachkontrolle (insbesondere bei Vigilanz-Verdacht) nicht wegfällt und eingerechnet werden muss.

Kosteneinsparung — niedrig (2/5) Die Einrichtungskosten liegen bei realistischen 15.000–35.000 Euro (API-Integration, QM-Prozessanpassung, Schulung, Testphase). Die direkten Laufkosten der Transkriptions-API sind gering — für 600 Anrufe à 10 Minuten pro Monat liegen sie unter 50 Euro. Die eigentliche Einsparung entsteht indirekt: weniger Personalaufwand für PMS-Berichte, vermiedene Bußgelder bei Meldefristversäumnis. Diese Einsparungen sind real, aber schwer präzise zu isolieren. Unter den Anwendungsfällen dieser Kategorie liegt die direkt messbare Kosteneinsparung im unteren Bereich.

Schnelle Umsetzung — niedrig (2/5) 8–14 Wochen bis zum Pilotbetrieb ist kein schlechter Wert für ein regulatorisches System — aber es ist nicht schnell. Die Technologie (Transkription) ist in wenigen Tagen eingerichtet. Was Zeit kostet, ist die Einbettung in das bestehende QM-System: Vigilanz-Trigger müssen definiert, Eskalationsprozesse dokumentiert, das System von der Benannten Stelle nachvollziehbar beschrieben werden. Dieser Aufwand ist nicht optional — er ist der Kern der regulatorischen Anforderung. Damit liegt dieser Anwendungsfall im unteren Quartil der Kategorie.

ROI-Sicherheit — sehr hoch (5/5) Das ist die stärkste Achse dieses Anwendungsfalls — und der Grund, warum er trotz hoher Einrichtungskosten und langer Umsetzungszeit sinnvoll ist. Ein einziger übersehener Vigilanz-Fall kann Bußgelder, behördliche Maßnahmen oder im schlimmsten Fall patientenseitige Haftungsansprüche auslösen. Der ROI dieser Lösung ist primär ein Compliance-ROI: Die Sicherheit, dass kein meldepflichtiges Vorkommnis im Rauschen der Alltagsanrufe untergeht. Dieser Nutzen ist unter den Anwendungsfällen dieser Kategorie am ehesten quantifizierbar — weil das Risiko, das vermieden wird, konkret benannt werden kann.

Skalierbarkeit — hoch (4/5) Mehr Anrufvolumen verursacht kaum mehr Betriebsaufwand — die API skaliert automatisch, die Kosten steigen linear mit dem Volumen (und bleiben gering). Was nicht vollständig skaliert: jede Änderung im Regulierungsrahmen (neue MDR-Leitlinien, EUDAMED-Anpassungen) erfordert eine Überprüfung der Vigilanz-Trigger-Logik. Dieser Wartungsaufwand ist moderat, aber real.

Richtwerte — stark abhängig von Anrufvolumen, bestehender IT-Infrastruktur und Reifegrad des QM-Systems.

Was das System konkret macht

Die technische Grundlage ist NLP-basierte Sprachverarbeitung in zwei Stufen:

Stufe 1 — Transkription: Das Gespräch wird nach dem Anruf (oder live) von einem Sprachmodell in Text umgewandelt. Für medizinische Fachsprache sind generische Transkriptionsmodelle ungeeignet — sie erzeugen hohe Fehlerquoten bei Gerätenamen, Fehlercodes und klinischen Begriffen. Medizinspezifische Modelle wie Deepgram Nova-3 Medical oder Whisper mit Fachvokabular-Anpassung erzielen deutlich bessere Ergebnisse, aber eine Fehlerquote von 3–7 % bleibt nach aktuellem Stand unvermeidlich — mehr dazu im Abschnitt zu Einstiegsfehlern.

Stufe 2 — strukturierte Extraktion: Ein LLM analysiert das Transkript und füllt ein strukturiertes Formular: Gerätebezeichnung und Seriennummer, beschriebenes Symptom oder Fehlercode, Patientenbezug (ja/nein), Schweregrad-Einschätzung (kein Schaden / möglicher Schaden / eindeutiger Schaden), und Vigilanz-Flag (ausgelöst / nicht ausgelöst). Die Klassifizierung erfolgt gegen eine vordefinierte Trigger-Liste.

Was das System nicht tut: Es ersetzt keine menschliche Einschätzung. Es stellt Hypothesen auf, keine Diagnosen. Jeder Anruf, der als „Vigilanz-verdächtig” markiert wird, geht zur menschlichen Prüfung. Jeder Eintrag, der ins QM-System übernommen wird, trägt den Namen der Person, die ihn freigegeben hat — nicht des Systems.

Die Architektur kann als API-Pipeline gebaut werden (Deepgram → GPT-4o / Claude via Azure → QM-System) oder über spezialisierte Call-Center-Analytics-Plattformen, die diese Schritte vorkonfiguriert bereitstellen.

Meldepflicht-Trigger: Wann der Anruf zum Vorkommnis wird

MDR Artikel 87 definiert drei Meldepflicht-Klassen mit unterschiedlichen Fristen — das KI-System muss diese Taxonomie kennen, um sinnvoll zu klassifizieren.

Klasse A — Sofortmeldung (≤ 2 Tage): Ernsthafte Bedrohung der öffentlichen Gesundheit. Auslöser im Hotline-Gespräch: Formulierungen wie „mehrere Patienten betroffen”, „Serienversagen”, „Systemausfall während Betrieb”, in Kombination mit Behandlungskontext.

Klasse B — Dringliche Meldung (≤ 10 Tage): Tod oder unerwartete schwerwiegende Verschlechterung des Gesundheitszustands. Auslöser: Jeder explizite Hinweis auf patientenseitige Konsequenz — „Patient musste hospitalisiert werden”, „Gerät versagte während der Behandlung”, „Verletzung”, auch wenn der Anrufer es bagatellisiert.

Klasse C — Standard-Meldung (≤ 15 Tage): Schwerwiegendes Vorkommnis ohne Todesfall. Auslöser: Gerätausfall in klinischer Situation, unerwartetes Verhalten, das theoretisch zu Schaden hätte führen können.

Trendsignale (keine Einzelfallmeldung, aber PMS-relevant): Wiederholte Fehler an demselben Gerätetyp, identische Symptome bei mehreren Kunden, Häufigkeitsänderungen bei bestimmten Fehlercodes. Das KI-System erkennt diese Muster beim zweiten oder dritten Auftreten — nicht erst bei der manuellen Quartalsauswertung.

Der kritische Satz für die Systemkonfiguration lautet: Der „Awareness Date” nach MDR beginnt, sobald der Hersteller Kenntnis erlangt — nicht erst, wenn ein Vigilanzbeauftragter den Bericht liest. Ein Hotline-Gespräch, das ein schwerwiegendes Vorkommnis beschreibt, startet die Frist. Das System muss dafür sorgen, dass diese Kenntnis umgehend die richtige Person erreicht.

Gesprächs-Taxonomie für die Post-Market Surveillance

Für den Automatisierungsbetrieb braucht ihr eine Taxonomie, die nicht nur Vigilanz-Fälle unterscheidet, sondern alle Anrufe so klassifiziert, dass sie für PMS-Berichte und Trendanalysen nutzbar sind.

Primäre Kategorien:

• Gerätebezogener Fehler (Hardware/Software/Firmware)
• Anwendungsfehler durch Bediener
• Zubehör-/Verbrauchsmaterialproblem
• Installations-/Inbetriebnahmefrage
• Routinewartung und Kalibrierungsanfrage
• Beschwerdeabwicklung ohne technischen Defekt (→ Überschneidung mit Beschwerdemanagement)

Sekundäre Attribute (immer erfassen):

• Gerätetyp und Produktfamilie
• Firmware-/Softwareversion (falls bekannt)
• Klinischer Kontext (ja/nein/unklar)
• Ergebnis (gelöst/eskaliert/Rückruf nötig)
• Vigilanz-Flag (keine Indikation / prüfen / meldepflichtig)

Diese Taxonomie muss in der Systemkonfiguration abgebildet sein — nicht nur als Nachschlageliste, sondern als strukturierter Output jedes Anruf-Eintrags. Erst dann lässt sich aus 600 Monatsgesprächen in zwei Stunden ein PMS-konformer Bericht ziehen, statt in zwei Tagen.

Konkrete Werkzeuge — was wann passt

Die technische Umsetzung hängt davon ab, wie viel Kontrolle ihr über den Datenstrom braucht und wie stark ihr QM-System integriert werden muss.

Deepgram Nova-3 Medical — wenn medizinische Präzision und EU-Compliance im Vordergrund stehen Das medizinspezifische Transkriptionsmodell erzielt deutlich bessere Ergebnisse bei Gerätenamen, Fehlercodes und klinischen Begriffen als Universalmodelle. EU-Endpoint verfügbar, Self-Hosted-Deployment für strikte DSGVO-Anforderungen. API-basiert, erfordert Entwicklerintegration. Kosten: ca. 0,007 USD/Minute — für 6.000 Anrufminuten/Monat unter 50 USD laufend.

Whisper (lokal/self-hosted) — wenn keine Audiodaten die eigene Infrastruktur verlassen dürfen OpenAIs Whisper lokal betrieben ist die einzige Option für Unternehmen, die Gesprächsaufnahmen absolut nicht in die Cloud übertragen können oder wollen. Qualitativ vergleichbar mit Deepgram, aber kein medizinspezifisches Modell. Benötigt GPU-Hardware (ca. 800 EUR/Monat für Cloud-VM) und Python-Know-how. Kein EU-Datentransfer-Risiko. Für Unternehmen mit eigenem IT-Betrieb die datenschutzrechtlich sicherste Variante.

Dragon Medical One — wenn kein Entwickler verfügbar ist und Telefonintegration nötig ist Dragon Medical One bietet fertige Integrationen für Klinik- und Praxissoftware und ist auf medizinische Fachsprache spezialisiert. Allerdings ist es primär für Diktat konzipiert, nicht für automatische Call-Transkription in einem Pipeline-Setup. Sinnvoll, wenn die Hotline-Mitarbeitenden nach dem Gespräch selbst diktieren statt zu tippen — aber kein automatischer Ansatz.

Fireflies.ai — wenn ihr schnell starten wollt und die Gespräche über Video-Call laufen Für Hotlines, die per Video-Call stattfinden (nicht klassisch per Telefon), kann Fireflies als Out-of-the-box-Lösung für Transkription und Zusammenfassung dienen. Datenhaltung in den USA — für sensitive MDR-Kontexte kritisch prüfen. Vigilanz-Logik müsste nachgelagert aufgebaut werden. Kein Ersatz für eine vollständige MDR-konforme Pipeline, aber ein Einstiegspunkt für erste Tests.

Zusammenfassung: Wann welcher Ansatz

• Maximale Genauigkeit und EU-Compliance → Deepgram Nova-3 Medical
• Absolut kein Cloud-Transfer → Whisper lokal selbst gehostet
• Kein Entwicklerteam, Diktat-basierter Workflow → Dragon Medical One
• Video-Hotline, schneller Start, Datenschutz klärbar → Fireflies.ai als Pilot

Datenschutz und Datenhaltung

Service-Hotline-Gespräche in der Medizintechnik enthalten fast immer personenbezogene Daten: Namen oder Identifikatoren der anrufenden Fachkräfte, gelegentlich patientenbezogene Beschreibungen, und technische Gerätedaten, die einer Institution zuordenbar sind. Das macht jeden Schritt der Verarbeitungskette DSGVO-relevant.

Kritische Punkte:

• Einwilligung oder Informationspflicht: Wer Anrufe aufnimmt und transkribiert, muss die anrufende Person vorab informieren. In Deutschland ist das keine Kann-Bestimmung. Die standardmäßige Ansage „Dieses Gespräch wird zu Qualitätssicherungszwecken aufgezeichnet” erfüllt die Informationspflicht — muss aber zwingend vor Gesprächsbeginn erfolgen.

• Auftragsverarbeitungsvertrag (AVV): Jeder externe Anbieter (Deepgram, Whisper-API, LLM-Anbieter), der Zugriff auf Gesprächsdaten hat, braucht einen AVV nach Art. 28 DSGVO. Das gilt auch für API-Nutzung ohne „menschlichen” Zugriff — technische Verarbeitung ist Verarbeitung.

• Besondere Kategorien (Art. 9 DSGVO): Sobald ein Gespräch Hinweise auf den Gesundheitszustand von Patienten enthält, greifen erhöhte Anforderungen. Viele Hotline-Anrufe berühren diese Kategorie — auch wenn nur beiläufig erwähnt.

• Datenresidenz: Für MDR-konforme Dokumentation gilt grundsätzlich: Aufbewahrungsfristen richten sich nach QMS-Anforderungen (ISO 13485: mindestens Lebensdauer des Produkts + 2 Jahre, oft 10–15 Jahre). Alle Daten müssen in diesem Zeitraum auffindbar und lesbar sein. EU-Hosting ist regulatorisch nicht explizit vorgeschrieben, aber für den Fall einer Behördenanfrage unkomplizierter.

• Empfehlung für MDR-Kontext: Deepgram mit EU-Endpoint und AVV oder Whisper self-hosted. Azure OpenAI Service in der EU-Region für LLM-Extraktion. Keine Lösung mit ausschließlicher US-Datenhaltung für produktive MDR-Workflows — das Risiko bei einem Audit ist schwer zu rechtfertigen.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

• API-Integration (Transkription + LLM-Extraktion): 3–8 Entwicklertage, je nach vorhandener QM-System-Schnittstelle
• Definition Vigilanz-Trigger-Taxonomie mit Regulatory Affairs: 2–4 Arbeitstage intern
• Testphase mit echten Anrufdaten, Validierung der Klassifizierungsgenauigkeit: 2–4 Wochen
• Dokumentation im QMS (Verfahrensanweisung, Validierungsprotokoll): 1–2 Wochen
• Externer Entwicklungsaufwand: ca. 5.000–15.000 Euro bei spezialisierten Dienstleistern
• Gesamt-Einrichtungskosten: 15.000–35.000 Euro, abhängig von IT-Infrastruktur und QMS-Komplexität

Laufende Kosten (monatlich)

• Deepgram Nova-3 Medical: ca. 30–80 USD je nach Anrufvolumen (typische Hotline: 500–1.200 Minuten/Monat × 0,007 $/Min)
• LLM-Extraktionsaufrufe (GPT-4o via Azure): ca. 20–60 Euro/Monat für strukturierte Analyse
• Infrastruktur/Hosting bei self-hosted Whisper: ca. 200–800 Euro/Monat

Was du dagegenrechnen kannst

• Dokumentationszeit je Anruf: 10–15 Minuten gespart × 500 Anrufe/Monat = ca. 80–120 Stunden/Monat × 25–40 Euro/Stunde = 2.000–4.800 Euro monatlich eingespart
• PMS-Berichtsaufwand: von 2 Tagen auf 2–4 Stunden je Quartal
• Vermiedene Bußgelder bei Meldefristversäumnis: Behörden können gemäß MDR Art. 113 erhebliche Sanktionen aussprechen — das Risikopotenzial übersteigt die Implementierungskosten erheblich

Konservative ROI-Rechnung: Bei 500 Anrufen/Monat und 10 Minuten Einsparung amortisiert sich die Einrichtung (30.000 Euro) innerhalb von 8–12 Monaten über direkte Personalzeit-Einsparung. Das Compliance-Risiko, das vermieden wird, ist nicht in dieser Rechnung — es macht das Vorhaben bei positivem Ergebnis noch attraktiver.

Typische Einstiegsfehler

1. Genauigkeit des Transkriptionsmodells falsch einschätzen. Das gefährlichste Missverständnis: „Das KI-System transkribiert alles.” Tut es nicht. Koenecke et al. (2024, PMC) dokumentierten in einer Studie zu Whisper-Einsatz in Krankenhäusern eine Halluzinationsrate von ca. 1 % der Transkriptionssamples — Fälle, in denen das Modell Sätze oder Phrasen generierte, die im Original nicht gesprochen wurden. Für einen einzelnen Anruf klingt 1 % harmlos. Bei 6.000 Anrufminuten pro Monat bedeutet das potenziell Dutzende fehlerhafter Passagen — mitten in Gesprächsaufzeichnungen, die für Vigilanz-Entscheidungen genutzt werden. Lösung: Jeder Eintrag, der ins QM-System übernommen wird, muss von einer qualifizierten Person geprüft und freigegeben werden. Keine Ausnahme — auch nicht bei niedrigem Schweregrad.

2. Die regulatorische Einbettung unterschätzen. Wer ein Transkriptions-Tool an die Hotline anschließt und glaubt, damit die MDR-Anforderungen zu erfüllen, irrt. Das Tool transkribiert — es dokumentiert nicht im regulatorischen Sinne. MDR-konforme Dokumentation erfordert: definiertes Verfahren im QMS, Verantwortlichkeiten, Freigabeprozess, Aufbewahrungsfristen, und eine nachvollziehbare Validierung des Systems. Ohne diese Umhüllung ist das KI-System kein Compliance-Werkzeug, sondern ein internes Notizblock-Tool. Lösung: Vor dem Launch muss eine Verfahrensanweisung für die KI-gestützte Hotline-Dokumentation im QMS verankert sein. Das ist Pflicht, kein Nice-to-have.

3. Vigilanz-Trigger zu eng oder zu weit definieren. Zu eng: Das System markiert nur explizite Aussagen wie „Der Patient ist gestorben” — und übersieht indirekte Hinweise wie „wir mussten den Eingriff abbrechen”. Zu weit: Jeder zweite Anruf wird als vigilanzrelevant markiert, der Beauftragte prüft 200 Fälle pro Monat und entwickelt „Alarm-Fatigue”. Beides entwertert das System. Lösung: Die Trigger-Definition gehört in einen Workshop mit Regulatory Affairs, einem erfahrenen Hotline-Mitarbeitenden und idealerweise externer Regulatory-Beratung. Mindestens vier Wochen vor Launch, nicht danach.

4. Das System nach dem Go-Live nicht warten. Gerätegenerationen wechseln, neue Fehlercodes kommen, MDR-Leitlinien werden aktualisiert. Ein Vigilanz-Trigger, der heute korrekt definiert ist, kann in 18 Monaten veraltet sein. Der gefährlichste Zustand ist ein System, das weiter läuft, als ob nichts wäre — während die Trigger-Basis nicht mehr zur aktuellen Produktgeneration passt. Lösung: Halbjährliche Trigger-Prüfung als festes QMS-Ereignis. Jede neue Produktfamilie oder Firmware-Version löst eine Trigger-Aktualisierung aus.

Was mit der Einführung wirklich passiert — und was nicht

Die Technologie ist das Einfachste an diesem Projekt. Das Schwierigere ist die Organisationseinbettung.

Drei typische Widerstände:

Die erfahrenen Hotline-Mitarbeitenden. Wer seit Jahren die Sprache der Kunden kennt, weiß oft intuitiv, welche Anrufe kritisch sind — auch wenn das nie explizit gemacht wurde. Ein KI-System, das diese Einschätzung formalisiert, kann sich anfühlen wie Überwachung oder Kompetenz-Abwertung. Konkrete Gegenstrategie: Die erfahrensten Hotline-Mitarbeitenden in die Trigger-Definition einbinden — nicht als Testende, sondern als Experten, ohne deren Wissen das System nicht korrekt konfiguriert werden kann. Wer das System mitgebaut hat, lehnt es nicht ab.

Der Regulatory Affairs-Beauftragte. „Wir haben das bisher auch so gemacht und keine Probleme gehabt.” Stimmt möglicherweise — aber es ist keine Aussage über Compliance, sondern über ausgebliebene Audits. Eine ehrliche Risikoabschätzung des Status quo ist oft das überzeugendste Argument für das Projekt.

Die IT-Abteilung. API-Integration, Cloud-Verarbeitung von Gesprächsdaten, AVV-Verhandlung mit US-Anbietern — das ist Aufwand, für den die IT selten Budget oder Zeit eingeplant hat. Frühzeitige Einbindung und ein klarer Scope sind entscheidend.

Was konkret hilft:

• Kick-off mit Regulatory Affairs, Hotline-Leitung und IT im ersten Monat — nicht sequenziell, sondern gleichzeitig
• Pilotphase mit 50–100 echten Anrufen, die im Nachgang manuell gegengeprüft werden — das erzeugt Vertrauen in die Systemleistung und zeigt Schwächen
• Klare Kommunikation: Das System entscheidet nicht, wer vigilanzverantwortlich ist. Die Person, die freigibt, bleibt verantwortlich.

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Die Validierungsphase ist keine optionale Qualitätskontrolle, sondern regulatorisch notwendig, wenn das System für Vigilanz-relevante Entscheidungen genutzt wird. Wer diesen Schritt spart, hat keine MDR-konforme Lösung — nur ein schnelleres Notizblock-Tool.

Häufige Einwände — und was dahintersteckt

„Unsere Hotline läuft auf Telefon, nicht auf Video — das funktioniert nicht mit KI.” Telefontranskription ist technisch genauso möglich wie Video-Transkription, und in einigen Aspekten einfacher. Anrufe können über eine Aufzeichnungsschnittstelle (Recording-API des Telefon-Systems) oder direkt aus dem CRM als MP3/WAV-Datei an die Transkriptions-API gegeben werden. Was nicht funktioniert: der automatische Bot-Beitritt à la Fireflies.ai — das ist eine Einschränkung bei Video-Meetings, kein generelles Problem.

„Die KI macht Fehler — das ist zu riskant für MDR-relevante Dokumentation.” Das stimmt — deshalb entscheidet die KI nicht. Sie erstellt einen Vorschlag, den ein Mensch freigibt. Der Unterschied zur Situation ohne KI: Heute dokumentiert der Mensch aus dem Gedächtnis nach dem Gespräch — mit allen Lücken und Interpretationsfehlern, die dabei entstehen. Das KI-Transkript ist das vollständige Gesprächsprotokoll als Grundlage, nicht ein Ersatz für menschliche Einschätzung. Die Fehlerrate des Systems muss im Validierungsprotokoll dokumentiert und als akzeptabel begründet sein — dann ist es MDR-konform.

„Wir haben kein Entwicklerteam für API-Integration.” Das ist ein valider Einwand, kein Vorwand. Ohne Entwicklerkapazität ist eine API-Pipeline nicht umsetzbar. Optionen: Externer Dienstleister für die Einrichtung (3–8 Entwicklertage, einmalig), oder Dragon Medical One als Diktat-basierter Ansatz ohne Pipeline-Aufwand. Wer wirklich keine technische Ressource hat, startet besser mit einem strukturierten Transkriptions-Workflow als manuellem Arbeitsschritt als mit einer halbfertigen Automatisierung.

Woran du merkst, dass das zu dir passt

• Ihr betreibt eine dedizierte Service-Hotline mit mindestens 5–10 eingehenden Anrufen täglich zu technischen Geräteproblemen
• Euer Vigilanzbeauftragter verbringt regelmäßig signifikante Zeit damit, historische Hotline-Tickets nach Mustern zu durchsuchen — statt Muster automatisch zu sehen
• Ihr habt eine etablierte MDR-konforme QM-Struktur (ISO 13485-Zertifizierung oder in Aufbau) — das System dockt an Prozesse an, es kann sie nicht ersetzen
• Eure Hotline-Mitarbeitenden sind keine Regulatory-Affairs-Experten — sie können zuverlässig nicht beurteilen, welche Anrufe vigilanzrelevant sind, ohne systematische Unterstützung
• Ihr habt oder plant EU-Datenhaltung für Produktdaten — das ist in dieser Branche die Grundvoraussetzung

Drei harte Ausschlusskriterien — wann dieser Anwendungsfall noch nicht passt:

1. Unter 10 Service-Calls täglich. Bei niedrigem Anrufvolumen übersteigt der Einrichtungsaufwand (15.000–35.000 Euro, 8–14 Wochen) den Nutzen deutlich. Unter dieser Schwelle ist ein strukturiertes Protokoll-Template mit verpflichtendem Vigilanz-Checkbox ausreichend — und in einer Stunde eingeführt.

2. Kein etabliertes QM-System. Wenn die Vigilanz-Prozesse noch nicht in einem QMS verankert sind, fehlt die Grundlage, an die das KI-System andocken soll. Die Investition in die QMS-Struktur kommt vor der KI-Investition. Ein KI-System auf einem nicht dokumentierten Vigilanz-Prozess macht den Prozess nicht MDR-konform — es verschleiert nur die Lücke.

3. Keine Ressource für menschliche Nachkontrolle. Ein KI-System, das ohne menschliche Prüfung Einträge ins QM-System schreibt, ist für MDR-relevante Dokumentation nicht akzeptabel. Wenn das Unternehmen nicht die Kapazität hat, jeden KI-generierten Eintrag von einer qualifizierten Person prüfen zu lassen, ist das System kein Compliance-Werkzeug — es ist eine potenzielle Haftungsfalle.

Das kannst du heute noch tun

Bevor ihr auch nur einen Euro in Technologie investiert: Analysiert 20–30 zurückliegende Hotline-Tickets auf Vollständigkeit und Konsistenz. Wie viele haben eine eindeutige Gerätebezeichnung? Wie viele beschreiben den klinischen Kontext? Wie viele hätten mögliche Vigilanz-Signale enthalten — und wurden sie als solche erkannt?

Diese Analyse kostet zwei bis drei Stunden und zeigt euch klarer als jede Machbarkeitsstudie, ob ihr ein Erkenntnisproblem oder ein Dokumentationsproblem habt — und was KI-Unterstützung konkret lösen würde.

Für den nächsten Schritt: Testet die Transkriptionsqualität mit echten Anrufaufzeichnungen. Hier ist ein Prompt, den ihr nach einer KI-Transkription zur strukturierten Extraktion verwenden könnt:

Quellen & Methodik

• MDR Art. 87 Meldefristen und Taxonomie: EU-Medizinprodukteverordnung (EU) 2017/745, Artikel 87–92. Volltext auf eur-lex.europa.eu verfügbar. Erläuterungen zur Klassifizierung: Johner Institut, „Vigilanzsystem für Medizinprodukte: Von der Idee zur Umsetzung”, Blog-Beitrag, 2024, blog.johner-institute.com/regulatory-affairs/vigilanz-system/
• Halluzinationsrate KI-Transkription: Koenecke et al., 2024, „Careless Whisper: Speech-to-text hallucination harms”, PubMed/PMC. Originalwert: ~1 % der Transkriptions-Samples enthielten Halluzinationen (kurze Phrasen bis vollständige Sätze), bereits in Krankenhäusern eingesetzt. Verweis: pmc.ncbi.nlm.nih.gov
• Wort-Fehlerrate medizinische Spracherkennung: Systematisches Review 2024, PMC: „Evaluating the performance of artificial intelligence-based speech recognition for clinical documentation” — allgemeine ASR-Systeme erzielen 7–11 % WER in medizinischen Umgebungen. Spezialmodelle (wie Dragon Medical One, Deepgram Nova-3 Medical) signifikant besser.
• Deepgram Preise (Nova-3): Deepgram Pricing-Seite, deepgram.com/pricing, Stand Mai 2026.
• Einrichtungskosten und Betriebskosten: Erfahrungswerte aus Implementierungsprojekten im Medizintechnik-Umfeld. Keine repräsentative Studie — Spanne abhängig von IT-Infrastruktur und QMS-Komplexität.
• MDR-Vigilanz als häufiger Audit-Mangelbefund: Johner Institut, 2024, ibid. — Vigilanz-Prozesse gehören zu den häufigsten Feststellungen bei MDR-Audits.

Du willst wissen, ob euer aktueller Hotline-Prozess MDR-konform ist — und was KI-Unterstützung konkret verändern würde? Das klären wir gerne in einem kurzen Gespräch.