Medical Scribes & MDR-Konformität: Leitfaden für medizinische Softwareanbieter

Spracherkennungstools mit medizinischem Fokus – auch bekannt als ‚Medical Scribes‘ – werden in Arztpraxen immer beliebter. Dabei ist zu beachten, dass diese Tools – wie jede Software im Gesundheitswesen – diversen regulatorischen Anforderungen unterliegen. In diesem Artikel versuchen wir, die Frage zu beantworten: Müssen Spracherkennungstools eine CE-Kennzeichnung haben – und warum?

Spracherkennung ist eine der spannendsten neuen Technologien im Gesundheitswesen. Das Prinzip dahinter ist einfach: Gesprochenes wird in Text umgewandelt. So müssen Ärztinnen und Ärzte keine Informationen mehr eintippen – sie sprechen einfach ihre Notizen in ein Mikrofon, und der Text erscheint direkt im genutzten System.

Studien zeigen, dass solche Tools tatsächlich Zeit sparen:

Ärztinnen und Ärzte, die Medical Scribes verwenden, dokumentieren 35–40 % schneller als mit herkömmlichen Methoden. Kein Wunder also, dass über 60 Unternehmen an solchen Lösungen arbeiten und führende Anbieter von EHR-Systemen – also Krankenhausinformationssystemen (KIS) und Praxisverwaltungssystemen (PVS) – entsprechende Funktionalitäten integrieren.

 

Quelle: https://cejsh.icm.edu.pl/cejsh/element/bwmeta1.element.ojs-doi-10_33119_EEIM_2020_58_4/c/2543-2328.pdf

Wie wir wissen, muss Software im Gesundheitswesen zahlreichen Vorschriften entsprechen, insbesondere in der EU. Spracherkennungstools stehen hier vor einer doppelten Herausforderung: Einerseits verarbeiten sie sensible Patientendaten aus Gesprächen, andererseits setzen sie künstliche Intelligenz zur Verbesserung der Spracherkennung ein. Diese Kombination bedeutet, dass Entwickler:innen mehrere regulatorische Rahmenbedingungen beachten müssen.

Im folgenden Artikel beleuchten wir die rechtliche Situation von Spracherkennungstools aus Sicht der Medical Device Regulation (MDR). Wir beantworten die Frage, ob – und in welchen Fällen – solche Software CE-kennzeichnungspflichtig ist.

Die Antwort hängt von vielen Faktoren ab. Lesen Sie weiter!

Inhaltsverzeichnis:

  • Funktionen der Medical Scribes
  • Medical Scribe und MDR
  • Wann fällt ein Medical Scribe nicht unter die MDR?
  • Wann fällt ein Medical Scribe unter die MDR?

Haftungsausschluss: Wir sind keine Anwaltskanzlei. Dieser Artikel dient nur dem besseren Verständnis der aktuellen Rechtslage. Für eine umfassende rechtliche Bewertung verweisen wir auf die Originaltexte der jeweiligen Vorschriften. Für professionelle Rechtsberatung empfehlen wir die Konsultation einer spezialisierten Kanzlei.

Haftungsausschluss 2: Dieser Artikel entspricht dem Stand zum Veröffentlichungszeitpunkt und wird bei Bedarf aktualisiert.

Funktionen der Medical Scribes

Zunächst sollten wir klären, über welche Art von Tools wir sprechen. Der Markt bietet eine Vielzahl an Lösungen mit unterschiedlichen Funktionen. Für diese Analyse unterscheiden wir vier Entwicklungsstufen von Speech-to-Text-Software für Ärztinnen und Ärzte – von einfachen Transkriptionshilfen bis hin zu vollumfänglichen klinischen Assistenten:

Level 0 – Einfache medizinische Transkription

  • Wandelt Sprache in einfachen Text um
  • Keine medizinische Strukturierung oder Formatierung
  • Hauptsächlich für Notizen, nicht für Patientengespräche gedacht
  • Beispiel: Diktierprogramme, die medizinische Begriffe wie „Ophthalmoplastik“ oder Abkürzungen wie „CRP“ korrekt erkennen

Level 1 – Transkription mit medizinischer Strukturierung

  • Wandelt Sprache in Text um
  • Strukturierung des Texts zu einer medizinischen Notiz (z. B. Anamnese, Untersuchung)
  • Teilweise mit Sprechererkennung
  • Interview-Zusammenfassung
  • Beispiel: Die Software transkribiert ein Arzt-Patienten-Gespräch in Echtzeit und strukturiert es als medizinisch verwertbare Notiz

Level 2 – Umgebungsabhörsystem + Interpretation

  • Hört Patientengespräch mit
  • Selektiert und filtert Informationen – nur relevante medizinische Inhalte werden dargestellt
  • Erstellt strukturierte Konsultationsnotizen nach Vorlage
  • Beispiel: Die Software erfasst ein Gespräch und generiert daraus eine strukturierte, medizinisch relevante Zusammenfassung, die direkt in die elektronische Krankenakte übernommen werden kann.
  •  

Level 3 – Fortgeschrittener klinischer Assistent

  • Enthält alle Funktionen von Level 2
  • Integration ins EHR (d.h. KIS oder PVS) mit Zugriff auf Patientendaten
  • Vorschläge zu ICD-Codes, Diagnosen und Verfahren
  • Identifizierung potenzieller Risiken und Kontraindikationen
  • Unterstützung bei Diagnostik und Therapie
  • Beispiel: Bei Brustschmerzen generiert der Assistent eine Notiz, schlägt mögliche Diagnosen vor, weist auf notwendige Untersuchungen hin, erkennt potenzielle Wechselwirkungen und schlägt passende ICD-Codes vor

Je höher die Tool-Stufe, desto komplexer und leistungsfähiger – und desto größer die regulatorischen Anforderungen.

Je mehr ärztliche Verantwortung ein Tool übernimmt, desto stärker ist es rechtlich geregelt.

Medical Scribe und MDR

Ob eine Software als Medizinprodukt gilt, klären folgende Dokumente:

Das Wichtigste ist die MDR 2017/745 – sie definiert Rahmenbedingungen für Qualifikation, Klassifikation und Zertifizierung von Software.

MDCG 2019-11 und MEDDEV 2.1/6 liefern unterstützende Richtlinien, die Herstellern dabei helfen, festzustellen, ob ihre Software als Medizinprodukt gilt und wie sie diese klassifizieren.

Was ist ein Medizinprodukt?

Nicht jede Gesundheitssoftware ist automatisch ein Medizinprodukt. In Erwägungsgrund (19) der MDR heißt es:

Software, die für medizinische Zwecke gemäß der Definition eines Medizinprodukts bestimmt ist, gilt als Medizinprodukt. Software allgemeiner Art – auch wenn sie im Gesundheitsbereich verwendet wird – ist kein Medizinprodukt.

Entscheidend ist also der „Verwendungszweck” (intended purpose) – wie vom Hersteller definiert.

Laut Artikel 2 MDR ist ein Medizinprodukt:

[…] jedes Instrument, Gerät, Software, Material oder sonstiger Artikel, das vom Hersteller für die Verwendung beim Menschen zu einem oder mehreren der folgenden medizinischen Zwecke bestimmt ist:

Diagnose, Vorbeugung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten, Verletzungen, Behinderungen […]

Der definierte Zweck legt fest, ob und wie Software als Medizinprodukt eingestuft wird – und somit auch ihre Klassifizierung (I, IIa, IIb, III) und Komplexität des Zertifizierungsprozesses. Dieser Zweck muss klar, ehrlich und nachvollziehbar dokumentiert werden.

Bei Medical Scribes ist die Abgrenzung oft schwierig: Ist ein Transkript eines Gesprächs reine Dokumentation – oder Teil der Diagnostik? Die Funktionen der Software sind entscheidend.

Wann fällt ein Medical Scribe nicht unter die MDR?

Um festzustellen, wann ein Tool nicht unter die MDR fällt, helfen die Richtlinien MDCG 2019-11 und MEDDEV 2.1/6. Bei Transkriptionstools kommt der Datenverarbeitung und -modifizierung eine besondere Bedeutung zu.

In MEDDEV 2.1/6 ist ein Entscheidungsbaum enthalten – Schritt 3 lautet:

Führt die Software eine andere Aktion mit Daten durch als Speicherung, Archivierung, Kommunikation oder einfache Suche?

Wenn nicht, ist sie kein Medizinprodukt.

Level 0 und 1 Tools (reine Transkription oder verlustfreie Strukturierung) fallen meist nicht unter die MDR. Sie zeichnen Informationen nur auf, speichern und zeigen sie an – ohne inhaltliche Änderungen.

Laut MEDDEV 2.1/6 gilt Software nicht als Medizinprodukt, wenn sie:

  • keine Daten verändert,
  • nur speichert, archiviert, überträgt oder einfach durchsucht,
  • verlustfrei komprimiert (d. h. die Originaldaten sind rekonstruierbar).

Fazit: Reine Transkription = technische Umwandlung ohne medizinische Interpretation.

Verlustfreie Strukturierung = Organisation, aber keine Veränderung.

Wann fällt ein Medical Scribe unter die MDR?

Sobald ein Tool mehr tut – z. B. Informationen auswertet, Wichtiges herausfiltert oder zusammenfasst – wird es möglicherweise medizinische Software.

Argumente finden sich in MEDDEV 2.1/6:

  • Seite 11: Software, die medizinische Informationen erzeugt oder verändert, um Ärztinnen und Ärzten bei der Interpretation zu unterstützen, kann ein Medizinprodukt sein.
  • Seite 11 (Beispiele für Datenverarbeitung):
    Dazu gehören: Mustererkennung, Klassifikation, Segmentierung, Bewertung, Modellierung, Visualisierung, Interpretation etc.
  • Seite 20 (Systeme zur Entscheidungsunterstützung):
    Software, die Patientendaten zusammenfasst, funktioniert ähnlich wie Systeme zur Entscheidungsunterstützung, da sie Patientendaten analysiert und Ärztinnen und Ärzten in organisierter Form Informationen bereitstellt, die ihre klinischen Entscheidungen unterstützen.
  • Seite 7 (Expertensoftware):
    Software, die vorhandene Informationen analysiert, um neue spezifische Informationen zu generieren, ist „Expertensoftware“.

Zusammengefasst:

Zusammenfassend lässt sich sagen: Wenn eine Spracherkennungssoftware neben der Transkription auch Informationen über eine Patientin oder einen Patienten (z. B. aus einem Gespräch) zusammenfassen und die wichtigsten Informationen auswählen kann, kann sie als Medizinprodukt eingestuft werden, weil:

  • sie über die reine Speicherung hinausgehende Datenverarbeitung vornimmt,
  • sie medizinische Informationen verändert oder neue erstellt,
  • sie den Entscheidungsprozess von Ärztinnen und Ärzten unterstützt,

sie direkten Einfluss auf Diagnose, Behandlung oder Überwachung einer Person haben kann.

 

Bei Level 3 ist die Einstufung eindeutig. Tools mit ICD-Vorschlägen, Therapieempfehlungen, Risikowarnungen erfüllen klar den Zweck von medizinischen Entscheidungsunterstützungssystemen – und sind als Medizinprodukt zu klassifizieren.

Fazit

Software, die LLMs zur Zusammenfassung medizinischer Informationen nutzt, wird wahrscheinlich als Medizinprodukt gelten, weil sie:

  • ärztliche Aufgaben übernimmt,
  • einen medizinischen Zweck verfolgt,
  • potenziell Einfluss auf Diagnose und Therapie hat.

Entscheidend für die Einstufung ist, wie stark die Software in ärztliche Entscheidungen eingreift.

Hersteller fortgeschrittener Systeme müssen:

  • CE-Kennzeichnung erlangen,
  • ein Qualitätsmanagementsystem umsetzen,
  • menschliche Kontrolle sicherstellen.

Wichtig: Dieser Artikel stellt unsere Interpretation der aktuellen Rechtslage dar. Bisher gibt es keine klaren offiziellen Aussagen der Behörden zu solchen KI-gestützten Lösungen.

Trotzdem integrieren immer mehr Anbieter in Europa Speech-to-Text-Funktionen.

Wenn Sie selbst ein System in diese Richtung entwickeln wollen – sehen Sie sich unsere Module für Softwareanbieter an. Wir haben bereits vorgearbeitet 😉

Kontakt

Hinterlassen Sie einfach Ihre E-Mail, und wir melden uns gerne bei Ihnen, um ein unverbindliches Online-Meeting zu vereinbaren und gemeinsam zu besprechen, wie wir uns gegenseitig unterstützen können.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert