Post-Market Surveillance Berichte automatisieren

Das echte Ausmaß des Problems

Post-Market Surveillance ist nach MDR 2017/745 nicht mehr optional. MDR Artikel 83 schreibt vor, dass jeder Hersteller ein PMS-System etablieren, dokumentieren und aufrechterhalten muss. Die Berichtspflichten sind konkret:

• PMSR (Post-Market Surveillance Report): für Klasse I und IIa Geräte, ohne feste Periodenfrequenz, aber bei jeder wesentlichen Änderung zu aktualisieren
• PSUR (Periodic Safety Update Report): für Klasse IIb und III alle 12 Monate, für Klasse IIa alle 24 Monate, mit exakt definierten Inhaltsvorgaben gemäß MDR Anhang III

Der Aufwand für eine vollständige PSUR-Erstellung liegt erfahrungsgemäß bei 40 bis 80 Arbeitsstunden pro Produkt und Zyklus, bei Unternehmen mit 5 oder mehr CE-zertifizierten Produkten der Klasse IIb/III bedeutet das: Mehrere Monate Vollzeit-Regulatory-Kapazität gebunden, nur für die Berichtspflicht.

Die Datenquellen sind das Problem. Ein vollständiger PSUR muss Daten aus mindestens diesen Quellen aggregieren:

• Beschwerdesystem (customer complaints, adverse events)
• Vigilanzmeldungen im EUDAMED
• Postmarket-Clinical-Follow-up-Daten (PMCF)
• Systematische Literaturrecherche (PubMed, Embase und andere)
• Registerdaten (wenn verfügbar)
• Marktdaten des eigenen Produkts und der Wettbewerber
• Daten aus Reparatur- und Servicemeldungen

Für die meisten mittelständischen Hersteller liegen diese Daten in vier bis sieben verschiedenen Systemen, und das manuelle Zusammenführen, Kategorisieren und Bewerten ist genau das, was KI strukturiert übernehmen kann.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Erfahrungswerte aus Implementierungsprojekten; stark abhängig von Datenqualität und Integrationsaufwand.

Der ROI ist bei PMS-Automatisierung direkter messbar als bei fast jedem anderen Regulatory-Anwendungsfall: Jeder verpasste Meldefristen-Termin kann zu einer CAPA, einem Audit-Befund oder einer Behördeninteraktion führen, alles messbare Ereignisse, die vor und nach der Einführung zählbar sind.

Einschätzung auf einen Blick

Zeitersparnis, sehr hoch (5/5) PMS-Berichtserstellung ist einer der zeitintensivsten Regulatory-Prozesse überhaupt, und einer der am wenigsten wertschöpfenden, weil er primär Datenaggregation und nicht inhaltliche Analyse ist. Genau hier ist KI am stärksten: Strukturierte Daten aus mehreren Quellen zusammenführen, kategorisieren, auf Trends prüfen. Die Zeitersparnis von 40 Stunden auf 15 Stunden pro Berichtszyklus ist konservativ gerechnet. In dieser Kategorie liegt dieser Anwendungsfall gleichauf mit der Technischen Dokumentation an der Spitze der Kategorie.

Kosteneinsparung, mittel (3/5) Die Einrichtungskosten von 25.000 bis 70.000 Euro sind real. Die Einsparungen entstehen über vermiedene externe Consulting-Kosten und, das ist der schwerer quantifizierbare Teil, über vermiedene Compliance-Risiken. Der direkte Stundeneinsparungswert ist bei mittelständischen Teams mit drei bis fünf Personen in Regulatory Affairs beachtlich, aber der ROI ist schwerer zu isolieren als bei der Technischen Dokumentation, wo Einreichungszyklen klar zählbar sind.

Schnelle Umsetzung, niedrig (2/5) Ähnlich wie bei der Technischen Dokumentation: Datenintegration aus mehreren Quellsystemen braucht Zeit. Beschwerdesystem-Export, EUDAMED-Anbindung, Literaturrecherche-Integration, jede dieser Verbindungen muss konfiguriert und validiert werden. 14 bis 20 Wochen bis zum ersten vollständig KI-gestützten PSUR sind realistisch.

ROI-Sicherheit, sehr hoch (5/5) Das ist der stärkste Punkt dieses Anwendungsfalls. Meldefristen sind binär: eingehalten oder nicht. Jeder PSUR hat einen festen Abgabetermin. Jede Stunde, die im Berichtszyklus eingespart wird, ist direkt messbar. Und die Alternative, ein verpasster PSUR-Termin, hat messbare Konsequenzen: CAPA-Pflicht, potenzielle Behördenaktion. Nirgendwo in der Regulatory-KI-Landschaft ist der Nutzenbeweis so eindeutig.

Skalierbarkeit, sehr hoch (5/5) Ein PMS-Automatisierungssystem, das für ein Produkt konfiguriert und validiert ist, lässt sich mit überschaubarem Mehraufwand auf weitere Produkte ausrollen. Für Hersteller mit wachsendem Portfolio ist das der entscheidende Hebel: Fünf Produkte bedeuten ohne KI fast fünf Mal so viel PSUR-Aufwand, mit KI liegt der Mehraufwand pro Produkt deutlich niedriger.

Richtwerte, stark abhängig von Produktportfolio, Datenqualität und vorhandener Dateninfrastruktur.

Was das System konkret macht

Ein KI-gestütztes PMS-System besteht aus drei logischen Schichten:

Datenaggregation und -normalisierung Die erste Herausforderung ist nicht Analyse, sondern Zusammenführung: Beschwerden kommen aus einem QMS-System, Vigilanzmeldungen aus EUDAMED, Literatur aus PubMed, Servicedaten aus einem separaten Field-Service-System. KI-gestützte Pipelines können diese Daten automatisch extrahieren, in ein einheitliches Format bringen und nach Produktzuordnung und Zeitraum filtern. Das ersetzt stundenlange manuelle Copy-Paste-Arbeit.

Trendanalyse und Muster-Erkennung Aus dem aggregierten Datensatz erkennt Machine Learning Muster, die einem Menschen bei 200 Beschwerdeeinträgen entgehen können: Häuft sich eine bestimmte Fehlerart in einer bestimmten Altersgruppe von Geräten? Gibt es einen saisonalen Trend bei Fehlermeldungen, der auf Umgebungseinflüsse hindeutet? Ist die Beschwerderate im Vergleich zum Vorjahr statistisch auffällig, oder innerhalb des normalen Schwankungsbereichs?

Berichtsgenerierung nach MDR Anhang III Auf Basis der analysierten Daten kann Generative KI strukturierte Berichtsentwürfe nach der vorgeschriebenen MDR-Gliederung erstellen. Abschnitte wie „Zusammenfassung der PMS-Daten”, „Trend-Analyse”, „Schlussfolgerungen zur Risiko-Nutzen-Bewertung” und „Konformitätserklärung” werden als Entwurfstext generiert, zur menschlichen Überarbeitung und Freigabe durch die verantwortliche Person.

Das Resultat: Die Regulatory-Mitarbeitenden verbringen ihre Zeit nicht mehr mit Datenzusammenführung und Schreiben von Standardabschnitten, sondern mit der inhaltlichen Bewertung und Freigabe, dem Teil, der tatsächliches Fachwissen erfordert.

Konkrete Werkzeuge, was wann passt

Greenlight Guru mit Post-Market-Modul, Das meistgenutzte spezialisierte Tool für medizintechnisches QMS bietet ein integriertes Post-Market-Modul, das Complaint Handling und PSUR-Workflow strukturiert. Vorteil: Beschwerden, Risikoregister und PSUR sind im gleichen System, ohne Datenmigration. Nachteil: US-Hosting, hohe Kosten, keine automatische Literaturrecherche-Integration out-of-the-box.

meddevo eTD, Für deutsche und europäische Hersteller bietet meddevo ein EU-gehostetes System mit MDR-spezifischen Workflows. Ob ein vollständiges PMS-Modul enthalten ist, hängt vom Implementierungsumfang ab, beim Anbieter direkt erfragen.

Spezialisierte PMS-Dienste (Metecon, Emergo by UL, NAMSA), Regulatory-Consulting-Firmen bieten PMS-as-a-Service an: Sie betreiben das PMS-System, führen Literaturrecherchen durch und erstellen den PSUR-Entwurf. Für kleinere Hersteller ohne interne Kapazität oft die pragmatischste Lösung, wenn auch langfristig teurer als ein eigenes System.

Claude AI mit strukturiertem Workflow, Für Teams mit begrenztem Budget: Ein LLM kann aus exportierten Beschwerdedaten Trendanalysen erstellen und PSUR-Abschnitte als Entwurf generieren. Kein integriertes System, keine automatische Datenanbindung, aber als erster Schritt zur Entlastung des Reporting-Aufwands wirksam. Der Einsatz muss im QMS dokumentiert sein.

Zusammenfassung: Wann welcher Ansatz

• Kleines Team, begrenzte Produktanzahl (1–3 Produkte) → PMS-Consulting-Dienst
• Integriertes QMS und PMS im gleichen System → Greenlight Guru
• EU-Hosting als Anforderung, deutschsprachiges Team → meddevo
• Überbrückungslösung oder Einstieg ohne Tool-Budget → Claude AI / ChatGPT mit Prompt

Rechtliche Besonderheiten

PMS nach MDR ist nicht nur eine Verwaltungsaufgabe, es ist ein kontinuierlicher Sicherheitsmechanismus. Die regulatorischen Anforderungen sind schärfer als bei der technischen Dokumentation:

MDR Artikel 87 (Vigilanz-Pflichten): Schwerwiegende Vorkommnisse müssen innerhalb von 15 Tagen (bei unmittelbarer Gefahr: 2 Tage) an die Behörde gemeldet werden. Ein KI-System, das Beschwerdedaten aggregiert, muss diese Fristen automatisch auslösen, was eine sorgfältige Konfiguration und Tests erfordert. Falsche Negative (ein schwerwiegendes Vorkommnis wird nicht als solches erkannt) sind ein erhebliches Compliance-Risiko.

Traceability-Anforderung: Die PMS-Daten müssen mit der Risikoanalyse des Produkts verknüpft sein. Ein neues Muster in den Beschwerdedaten muss zur Risikoakte führen und eine Bewertung auslösen. KI-Systeme, die diese Verbindung nicht automatisch herstellen, erzeugen manuelle Nacharbeit.

EUDAMED-Pflichten: Seit 2024 sind Hersteller verpflichtet, PSURs in EUDAMED einzureichen. Wenn das KI-System den PSUR generiert, muss der Output EUDAMED-kompatibel sein oder manuell konvertiert werden.

Datenschutz und Datenhaltung

PMS-Daten können personenbezogene Daten enthalten: Beschwerden von Patienten oder medizinischem Fachpersonal, die Informationen über Diagnosen oder Behandlungen enthalten. Die DSGVO-Anforderungen sind daher direkt relevant:

• Beschwerdedaten dürfen in der Regel nicht direkt an US-Cloud-Dienste übertragen werden, es sei denn, die Daten sind vorher pseudonymisiert und ein AVV liegt vor
• Für Klinische Daten aus PMCF-Studien gelten zusätzliche Anforderungen aus dem EU-Datenschutzrecht
• Lösung: Pseudonymisierung der Beschwerdedaten vor KI-Verarbeitung, die medizinisch relevante Information (Art des Vorkommnisses, Gerätepartie, Nutzungsbedingungen) kann behalten werden, personenbezogene Identifikatoren werden entfernt
• EU-gehostete Systeme (meddevo) vermeiden dieses Problem weitgehend, aber der AVV muss auch dort abgeschlossen werden

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

• Systemauswahl und Datenintegration: 20.000–50.000 Euro bei eQMS-Tools mit PMS-Modul
• Integration der Datenquellen (Beschwerdesystem, EUDAMED-Export, Literatur-API): 5.000–20.000 Euro Implementierungsaufwand
• Validierung im QMS: 30–50 Stunden Regulatory-/QM-Zeit
• Bei LLM-basiertem Ansatz: deutlich weniger, primär interne Personalzeit

Laufende Kosten (monatlich)

• eQMS mit PMS-Modul: 1.500–3.500 Euro/Monat
• Spezialisierter PMS-Consulting-Dienst: 2.000–8.000 Euro/PSUR-Zyklus
• LLM-Nutzung: 50–200 Euro/Monat

Was du dagegenrechnen kannst 40 Stunden PSUR-Erstellung × 4 Produkte pro Jahr × interner Stundensatz 60–100 Euro: 9.600 bis 16.000 Euro interner Aufwand pro Jahr, nur für die Reporterstellung, ohne Datenrecherche. Dazu kommen externe Consulting-Kosten, wenn das Team die Last nicht trägt. Und: ein verpasster PSUR-Termin kann eine Notified-Body-Intervention auslösen, die weit teurer ist als das System selbst.

Wie du den Nutzen tatsächlich misst Dokumentiere vor der Einführung: Wie viele Stunden kostet ein PSUR-Zyklus? Wie viele externe Consultant-Stunden werden eingesetzt? Wie viele Meldefrist-Warnungen gab es in den letzten 12 Monaten? Nach 12 Monaten mit dem System werden alle drei Zahlen gesunken sein, wenn nicht, war die Konfiguration unzureichend.

Typische Einstiegsfehler

1. Literaturrecherche ausschließlich automatisieren, ohne fachliche Qualitätsprüfung. KI kann systematische Literaturrecherchen erheblich beschleunigen, aber die Relevanzbeurteilung klinischer Publikationen für ein spezifisches Medizinprodukt ist eine inhaltliche Aufgabe, die Fachkenntnisse erfordert. Ein Algorithmus, der Studien nach Keyword-Treffer sortiert, kann relevante Publikationen übersehen und irrelevante einschließen. Die Qualitätsprüfung der KI-Vorauswahl durch eine Fachperson ist kein optionaler Schritt, sondern Pflicht.

2. PMS als IT-Projekt behandeln, nicht als Regulatory-Prozess. PMS-Automatisierung wird manchmal als technisches Integrationsprojekt gestartet, Systeme verbinden, Daten fließen lassen. Das Problem: Wenn das Regulatory-Team nicht von Anfang an definiert, welche Daten wie bewertet werden sollen, entsteht ein gut laufendes System, das die falschen Fragen beantwortet. Wer definiert, was ein “Trend” ist? Wer entscheidet, ab welcher Häufungszahl eine CAPA ausgelöst wird? Diese Entscheidungen müssen vor der Implementierung, nicht nach ihr, getroffen werden.

3. Keine kontinuierliche Datenpflege des Beschwerde-Inputs. Ein PSUR-System ist so gut wie die Daten, die hineingehen. Wenn Beschwerden unvollständig, fehlerhaft kategorisiert oder mit Verzögerung eingegeben werden, produziert das System eine schöne Hülle mit zweifelhaftem Inhalt. Die Datenqualität des Beschwerdesystems muss parallel zur PMS-Automatisierung verbessert werden, das ist oft der aufwendigere Part.

4. Die Eskalationskette für schwerwiegende Vorkommnisse nicht vorab konfigurieren. Wenn das System automatisch Daten aggregiert und ein Muster erkennt, das wie ein schwerwiegendes Vorkommnis aussieht, wer wird informiert? In welchem Zeitfenster? Was passiert, wenn die zuständige Person im Urlaub ist? Diese Eskalationslogik muss vor dem Go-Live getestet sein, nicht nach dem ersten echten Ereignis.

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

PMS-Automatisierung ist politisch sensibler als die meisten anderen KI-Projekte im Regulatory-Bereich, weil PMS-Berichte direkt in der Verantwortung der Person mit der Rolle des “Person Responsible for Regulatory Compliance” (PRRC) gemäß MDR Artikel 15 liegen. Diese Person trägt persönliche Verantwortung.

Was das in der Praxis bedeutet: Die PRRC ist sehr vorsichtig dabei, KI-generierte Inhalte zu unterschreiben, und das ist richtig so. Was hilft:

• Das System muss transparent zeigen, woher jede Aussage im PSUR-Entwurf stammt (Quellenangabe auf Zeilenebene)
• Jede KI-generierte Aussage muss vom Regulatory-Experten inhaltlich geprüft und explizit bestätigt werden, kein “Auto-Approve”
• Die Validierungsdokumentation des Systems muss zeigen, dass das System keine Vorkommnisse übersieht (False-Negative-Rate)

Das QM-Team stellt die zweite Widerstandslinie dar. In Unternehmen mit etabliertem ISO-13485-QMS gibt es oft eine interne Diskussion darüber, ob ein KI-Assistent im PMS-Prozess als “Methode” validiert werden muss oder als “Software im QMS”, mit unterschiedlichen Validierungsanforderungen. Diese Diskussion frühzeitig führen und einen Konsens mit der Qualitätsleitung herstellen, bevor das Projekt startet.

Was konkret hilft:

• Einen Piloten mit einem einzigen PSUR-Zyklus eines weniger kritischen Produkts starten
• Den PSUR-Entwurf des Systems mit einem parallel manuell erstellten Entwurf vergleichen, erst wenn beide inhaltlich äquivalent sind, den manuellen Weg ablösen
• Die Freigabedokumentation von Anfang an so gestalten, dass der menschliche Überprüfungsschritt explizit und nachvollziehbar ist

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir haben nur drei Produkte, das lohnt sich nicht.” Drei Klasse-IIb-Produkte bedeuten drei PSURs pro Jahr, das sind 120 bis 240 Stunden pro Jahr nur für die Reporterstellung, ohne Datenrecherche. Bei einem internen Stundensatz von 70 Euro sind das 8.400 bis 16.800 Euro jährlich. Ob ein System bei 3 Produkten schon rechnet, hängt stark von den Tool-Kosten ab, für 3 Produkte könnte ein LLM-gestützter Ansatz ohne großes Tool-Investment die sinnvollere Alternative sein.

„Die PRRC will keine KI-generierten Berichte unterschreiben.” Das ist ein berechtigter Einwand, kein Widerstand. Die Lösung ist nicht, die PRRC zu überzeugen, sondern das System so zu bauen, dass die PRRC genau sehen kann, welche Quellen hinter welcher Aussage stecken, und explizit jede Aussage bestätigt. Das System spart Zeit beim Zusammenstellen, nicht beim Denken.

„Unsere Beschwerdedaten sind zu unstrukturiert für KI.” Unstrukturierte Daten (Freitext-Beschwerden) sind genau das, bei dem NLP besonders gut ist: automatische Kategorisierung, Sentimentanalyse, Erkennung wiederkehrender Formulierungen. Der erste Schritt ist nicht eine bessere Eingabemaske, sondern eine Analyse, welche Informationen in vorhandenen Freitexten versteckt sind und wie sie strukturiert werden können.

Woran du merkst, dass das zu dir passt

• Dein Team verbringt jedes Quartal mehrere Wochen mit der Erstellung von PSUR- oder PMSR-Berichten, und das Regulatory-Team hat daneben wenig Zeit für andere Aufgaben
• Ihr habt mehr als zwei Produkte der Klasse IIb oder III, der Pflege- und Berichtsaufwand skaliert linear mit der Produktanzahl
• Beschwerden oder Vorkommnisse kommen aus mehreren Systemen und müssen manuell zusammengeführt werden
• Die letzten Audits haben PMS-Prozess-Lücken bemängelt, nicht fehlende Daten, sondern fehlende Konsistenz oder Struktur
• Das Team wächst und neues Personal soll schnell eigenständig PSUR-Daten auswerten können

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Nur Klasse-I-Produkte ohne erhöhten PMS-Bedarf. PMSR-Anforderungen für Klasse I sind weniger stringent, der Investitionsaufwand für ein vollständiges PMS-Automatisierungssystem ist dann nicht gerechtfertigt.

2. Keine strukturierte Datenbasis für Beschwerden. Wenn Beschwerden in einer Excel-Tabelle ohne einheitliche Felder oder gar nur als E-Mail-Archive vorliegen, ist die erste Priorität die Strukturierung des Beschwerdeprozesses, nicht die Automatisierung. KI auf unstrukturierten Input loszulassen, ohne die Datenqualität zu kennen, produziert nicht verlässliche Ausgaben.

3. Keine PRRC oder Regulatory-Affairs-Expertise intern. PMS-Automatisierung setzt voraus, dass jemand die KI-generierten Entwürfe inhaltlich prüfen und verantworten kann. Ohne diese Expertise intern wird das System zu einem Compliance-Risiko, nicht zur Entlastung.

Das kannst du heute noch tun

Starte mit einem konkreten Piloten: Exportiere die Beschwerdedaten des letzten PSUR-Zyklus aus deinem QMS (oder Excel) und lade sie in einen KI-Assistenten. Verwende diesen Prompt:

Quellen & Methodik

• PMS-Anforderungen MDR: Verordnung (EU) 2017/745, Artikel 83–86, Anhang III (PSUR-Inhalt), in der aktuell gültigen Fassung.
• PSUR-Frequenz Klasse IIb/III jährlich, IIa zweijährlich: MDR Artikel 86 Absatz 6–7.
• PMSR/PSUR Anforderungen: NAMSA, „Periodic Summary Update Report und PSUR zur Einhaltung der MDR” (2024); Emergo by UL, „PMS and PSUR Requirements Under the European MDR” (2024).
• Erfahrungswerte 40–80 Stunden PSUR-Aufwand: Erfahrungswerte aus Regulatory-Consulting-Projekten von Metecon, NAMSA und anderen (kumuliert aus öffentlich zugänglichen Beratungshinweisen, nicht als repräsentative Erhebung).
• Vigilanzpflichten 15-Tage-Frist: MDR Artikel 87 Absatz 1.
• Art. 28 DSGVO (AVV): Datenschutz-Grundverordnung in der aktuell gültigen Fassung.

Du willst wissen, ob sich ein PMS-Automatisierungssystem für euer Produktportfolio rechnet? Meld dich, das rechnen wir konkret durch.