Klinische Anforderungen aus Literaturdaten für Produktentwicklung extrahieren

Das echte Ausmaß des Problems

Klinische Evidenz für Design Inputs ist keine Kür, sie ist regulatorische Pflicht. Artikel 61 der MDR 2017/745 verlangt, dass Hersteller klinische Daten vorlegen, die die Konformität ihres Produkts mit den grundlegenden Sicherheits- und Leistungsanforderungen (GSPRs) nach Anhang I belegen. Konkret: Woher stammt die Spezifikation, dass euer Blutdruckmessgerät auf ±5 mmHg genau sein soll? Was sagt die Literatur zur klinisch akzeptierten Messtoleranz für diese Patientenpopulation und diesen Anwendungskontext?

Die Antwort muss dokumentiert sein, vor dem Design Output, nicht nachträglich.

In der Praxis sieht das so aus: Für jedes Leistungsmerkmal, das in den Design Inputs spezifiziert ist, braucht das Team eine belegte Begründung. Das reicht von Messgenauigkeiten über Alarmgrenzen bis zu Materialverträglichkeiten. Laut Schätzungen aus MedTech-Consulting-Praxis dauert die initiale Literatursichtung für eine neue Produktkategorie drei bis sechs Wochen, wenn sie nach MEDDEV 2.7/1 Rev. 4-Standard strukturiert durchgeführt wird, mit PICO-Rahmen, mindestens zwei Datenbanken (PubMed und Embase gelten als Minimum), Duplikat-Screening, Volltext-Review und PRISMA-konformer Dokumentation.

Das Problem verschärft sich durch zwei weitere Faktoren:

• Frühe Entwicklungsphasen haben wenig Puffer. Wenn die Design Inputs nicht solide belegt sind, beginnt der gesamte Design-Control-Prozess auf wackeligem Fundament. Änderungen später, besonders nach der Verifikation, sind teuer, zeitintensiv und benötigen erneute Design Reviews mit allen Unterschriften.

• Benannte Stellen prüfen die Quellenqualität zunehmend strenger. Seit MDR-Geltungsbeginn 2021 ist die Ablehnungsquote bei unzureichend belegten Clinical Evaluation Reports (CERs) und Design-Input-Dokumenten deutlich gestiegen. Eine systematische Übersichtsarbeit in Journal of Medical Devices (2023) stellte fest, dass unvollständige Literaturbelege einer der häufigsten Gründe für Rückmeldungen der Benannten Stellen im ersten Prüfzyklus sind.

Der Engpass ist kein Ressourcenproblem allein. Er ist strukturell: Eine saubere Literatursynthese braucht sowohl die klinische Einordnungskompetenz des Facharzts als auch die Methodikkompetenz des Systematic-Review-Experten, und die meisten KMU-MedTech-Teams haben beides nicht in Vollzeit in-house.

Die regulatorische Logik dahinter

Wer Design Inputs in der Medizintechnik erstellt, bewegt sich in einem Geflecht aus regulatorischen Anforderungen, die alle auf dasselbe Fundament zeigen: belegte Evidenz.

MDR 2017/745 Anhang I (GSPRs): Die allgemeinen Sicherheits- und Leistungsanforderungen müssen durch klinische Daten belegt sein. Nicht durch Annahmen, nicht durch interne Tests allein, sondern durch den Nachweis, dass das gewählte Design dem klinischen Stand der Technik entspricht.

ISO 14971, Risikoanalyse und Hazard Identification: Die Norm verlangt, dass bekannte und vorhersehbare Risiken identifiziert werden. Woher kommen diese? Primär aus der Literatur: publizierte Fallberichte, Adverse Event Databases (FDA MAUDE, EUDAMED), systematische Reviews zur Sicherheit vergleichbarer Produkte. Design Inputs, die die Sicherheitsgrenzen eines Geräts festlegen, müssen auf diese Evidenzbasis zurückgehen.

MEDDEV 2.7/1 Rev. 4, Systematic Literature Search: Dieses Guidance Document der Europäischen Kommission definiert die Mindestanforderungen für eine klinische Literatursuche. PICO-Framework, mindestens PubMed und Embase, dokumentierte Suchstrategie, PRISMA-Flussdiagramm, Appraisal der eingeschlossenen Studien. Diese Anforderungen gelten nicht nur für den Clinical Evaluation Report, sie informieren auch, welcher Evidenzstandard von einer Benannten Stelle für Design-Input-Belege erwartet wird.

Anhang XIV MDR, PMCF: Selbst nach der Zulassung hat der Hersteller eine Verpflichtung zur kontinuierlichen Literaturüberwachung im Rahmen des Post-Market Clinical Follow-up. Was im Design-Input-Stadium etabliert wurde, muss in der PMCF-Routine fortgeschrieben werden. Ein robustes Literatursystem in der Entwicklungsphase ist also nicht nur Pflicht, es ist die Basis für ein langfristig tragfähiges PMS/PMCF-Programm.

Das bedeutet: KI-gestützte Literatursynthese löst nicht das regulatorische Anforderungsproblem. Sie beschleunigt den Prozess der Evidenzsammlung. Die Methodenqualität und die klinische Validierung der Ergebnisse bleiben menschliche Aufgaben.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Zeitersparnis gilt für das Screening und die Extraktion. Die klinische Bewertung der Evidenzqualität und die Validierung der abgeleiteten Design-Input-Werte durch Fachleute (Clinical Evaluation Specialist oder klinischer Experte) dauert unverändert.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5) Die Zeitersparnis ist real und messbar: Statt drei bis sechs Wochen manueller Literatursichtung braucht ein gut aufgesetztes KI-System für Abstract-Screening und Ersatz-Extraktion eine bis zwei Wochen. Das ist der stärkste Hebel dieses Use Case, und in der Entwicklungspraxis der einzige, der ohne Kompromisse bei der regulatorischen Qualität funktioniert. Vier statt fünf Punkte, weil die Zeitersparnis für Validierung und klinische Bewertung der extrahierten Werte null ist.

Kosteneinsparung, niedrig (2/5) Die direkte Kosteneinsparung ist begrenzt. Tool-Lizenzen kosten Geld, der Validierungsaufwand im QMS kostet Geld, und der Clinical Evaluation Specialist, der die KI-Ergebnisse prüft, kostet Geld. Der Nutzen entsteht vor allem durch kürzere Entwicklungszyklen und weniger Rückfragen der Benannten Stelle, aber der ist schwer in Euro-Einsparungen umzurechnen. Anders als bei der Technischen Dokumentation nach MDR, wo Zeitaufwand pro Dokument direkt skaliert, bleibt der Kliniker-Stundensatz ein fixer Posten.

Schnelle Umsetzung, niedrig (2/5) Bevor du ein KI-gestütztes Literatursystem produktiv einsetzt, muss es in euer QMS integriert sein: eine SOP für den AI-unterstützten Review-Workflow, ein Validierungsprotokoll für das Tool selbst (zumindest für die Extraktion), eine Definition, welche KI-Outputs als Evidenz-Input in Design-Input-Dokumente einfließen dürfen und welche nochmals durch einen Reviewer validiert werden müssen. Das sind acht bis sechzehn Wochen realistische Vorlaufzeit in einem strukturierten Qualitätsmanagementsystem, keine Komplexitätshürde, aber auch kein Wochenend-Setup.

ROI-Sicherheit, sehr niedrig (1/5) Das ist der schwächste Punkt und der ehrlichste: Die Benannte Stelle akzeptiert keine KI-generierten Schlussfolgerungen ohne klinische Expertenvalidierung. Das heißt, der Herzstück-Aufwand, die Bewertung, ob ein literaturbasierter Performance-Benchmark tatsächlich als Design Input verwendet werden darf, bleibt bei Fachleuten. Außerdem lässt sich der Nutzen eines besseren Design-Input-Prozesses kaum in Euro messen: War die Benannte Stelle zufrieden, weil die KI-gestützte Recherche besser war, oder wegen anderer Faktoren? Dieser Use Case wird nach Zeitgefühl bewertet, nicht nach Kennzahlen.

Skalierbarkeit, mittel (3/5) Ein etablierter Review-Workflow für Produktkategorie A kann grundsätzlich auf Produktkategorie B übertragen werden. Aber: Suchstrategien, PICO-Rahmen und Extraktionsparameter sind produktspezifisch. Für ein neues Produktfeld braucht es erneut einen Clinical Expert, der die relevanten Outcomes definiert, und eine neue Validierungsdurchführung. Mittelwert, nicht schlecht, aber auch kein Push-Button-System.

Richtwerte, stark abhängig von Produktklasse, Komplexität der klinischen Indikation und internen QMS-Anforderungen.

Was das System konkret macht

Die technische Grundlage ist ein kombinierter Ansatz: Screening-Automatisierung trifft auf LLM-gestützte Datenextraktion.

Schritt 1, Datenbankexport und Deduplizierung. Die Suche selbst läuft nach wie vor in den Fachdatenbanken, PubMed, Embase, Cochrane Library, bei Bedarf Scopus. Der Export landet als RIS- oder NBIB-Datei im Screening-Tool. Tools wie Rayyan oder Covidence übernehmen dann die Deduplizierung automatisch.

Schritt 2, KI-gestütztes Abstract-Screening. Das Screening-Tool priorisiert Treffer nach vorher definierten Inklusions- und Exklusionskriterien. Nach den ersten 50–100 manuellen Entscheidungen lernt die KI, welche Paper relevant sind, und sortiert die verbleibenden Treffer entsprechend, relevanteste Papers oben. Studien berichten von 35–80 % Reduktion des Screening-Aufwands bei gleichbleibender Trefferquote für relevante Evidenz (DistillerSR-Validierungsdaten, 2024).

Schritt 3, Strukturierte Datenextraktion. Aus den eingeschlossenen Volltexten extrahiert das System vorläufig die für Design Inputs relevanten Parameter: Patientenpopulation, Messverfahren, Performance-Benchmarks (Sensitivität, Spezifität, Messgenauigkeit), Studiengröße, Qualitätsindikatoren. Tools wie Elicit oder DistillerSR erstellen spaltenbasierte Extraktionstabellen, die dann durch den Clinical-Evidence-Koordinator validiert werden.

Schritt 4, Synthese und Anforderungsableitung. Ein LLM wie Claude oder ChatGPT erhält die validierten Extraktionstabellen und fasst die belegte Evidenzlage für jeden Design-Input-Parameter zusammen: „Fünf unabhängige Studien mit insgesamt 2.347 Patienten zeigen, dass ein Alarmgrenzwert von X % Sensitivität dem klinischen Standard entspricht. Referenzen: [Liste mit DOIs].” Diese Synthese geht dann in die Design-Input-Dokumentation und wird vom klinischen Verantwortlichen freigegeben.

Was bleibt menschliche Aufgabe: Die Bewertung der Studienqualität, die Entscheidung zur Äquivalenz (ist das verglichene Produkt wirklich vergleichbar?), die klinische Plausibilitätsprüfung der abgeleiteten Anforderungen und die formale Freigabe für die Design-Input-Dokumentation. Kein Tool ersetzt diese Schritte, das ist Absicht, nicht Schwäche des Ansatzes.

Was der Benannten Stelle wirklich wichtig ist

Das ist die Frage, die über den Erfolg des gesamten Ansatzes entscheidet, und die von den meisten Teams zu spät gestellt wird.

Benannte Stellen wie TÜV Rheinland, TÜV SÜD, BSI oder DNV prüfen bei Design-Input-Dokumentation nicht nur, ob Quellen vorhanden sind. Sie prüfen die Methodik: Wurde systematisch gesucht oder ad hoc? Sind die Suchstrings und Datenbanken dokumentiert? Gibt es ein PRISMA-Flussdiagramm? Sind die Inklusions- und Exklusionskriterien vorab definiert (prospektiv) oder erst nach der Suche festgelegt (retrospektiv, Bias-Risiko)? Sind Studienlimitationen diskutiert?

Was das für KI-gestützte Workflows bedeutet:

• KI-Outputs müssen in einem auditierbaren Protokoll dokumentiert sein: welcher Prompt wurde verwendet, welche Papers wurden ein- oder ausgeschlossen und warum, welche Extraktionsentscheidungen wurden durch den KI-Vorschlag beeinflusst vs. durch den Reviewer überschrieben.
• Das Screening-Tool muss entweder im QMS-Kontext validiert oder seine Nutzung mit einer klaren Begründung dokumentiert sein, warum es für diesen Anwendungsfall geeignet ist.
• Alle Schlussfolgerungen, „Dieser Performance-Wert entspricht dem klinischen Stand der Technik”, müssen von einem qualifizierten klinischen Experten unterzeichnet sein, nicht vom KI-Tool.

Praxistipp: Bevor ihr ein Tool einführt, schreibt den Methodenabschnitt des Literaturnachweises schon einmal als Entwurf. Wenn ihr nicht beschreiben könnt, wie die KI in die Entscheidungskette eingeflossen ist und wer welche Entscheidungen getroffen hat, habt ihr die Integration noch nicht fertig gedacht.

Konkrete Werkzeuge, was wann passt

Der sinnvollste Ansatz ist ein Tool-Stack, weil kein einzelnes Tool den gesamten Prozess abdeckt.

Rayyan, Kostenloser Einstieg ins Screening Rayyan ist der pragmatischste Startpunkt: kostenfrei für bis zu drei aktive Reviews, PRISMA-Flussdiagramm automatisch, KI-Priorisierung nach den ersten Entscheidungen. Für den Start eines neuen Literaturreviews zu einem Design-Input-Thema ist das ausreichend. Einschränkung: US-Hosting, kein AVV im kostenfreien Plan, für medizinische Nicht-Patientendaten (öffentliche Fachliteratur) von vielen Teams akzeptiert, aber mit dem Datenschutzbeauftragten klären.

Elicit, Strukturierte Datenextraktion Elicit Pro (49 USD/Monat) extrahiert automatisch Studiendesign, Stichprobengrößen und primäre Endpunkte aus Abstracts in konfigurierbaren Tabellenspalten. Für Design-Input-Extraktion (Was ist der gemessene Wert? Was ist die Patientenpopulation? Was sind die Konfidenzintervalle?) spart das gegenüber manueller Extraktion deutlich Zeit. Auch Elicit hostet in den USA, DSGVO-Einordnung wie bei Rayyan.

DistillerSR, Audit-ready für regulatorische Submissions DistillerSR ist die Enterprise-Wahl für Unternehmen, die regelmäßig CERs und Design-Input-Literaturreviews für Benannte Stellen einreichen. Laut Anbieter nutzen mehr als 70 % der weltweit 20 größten Pharma- und MedTech-Unternehmen die Plattform. AI Rerank reduziert den Screening-Aufwand im Median um 47 % bei 95 % Recall; jede KI-Entscheidung erfordert menschliche Bestätigung, das ist regulatorisch akzeptabel. Vorteil: vollständiger Audit-Trail im System, direkt als Methodenanlage exportierbar. Nachteil: Preis auf Anfrage, typischerweise Enterprise-Budget; ebenfalls US-Hosting.

Claude oder ChatGPT, Synthese und Anforderungsformulierung Wenn die Extraktionstabelle aus Rayyan, Elicit oder DistillerSR vorliegt und manuell validiert wurde, übernimmt ein LLM die Syntheseaufgabe: Formulierung der belegten Evidenzaussage, Strukturierung nach Design-Input-Parametern, Formulierung des Methodenabschnitts für das Anforderungsdokument. Wichtig: Die Extraktionstabelle muss vorab vom Clinical-Evidence-Koordinator geprüft sein, das LLM synthetisiert, was man ihm gibt. Gibt man ihm ungeprüfte KI-Extrakte, produziert es selbstsicher wirkende Anforderungen auf wackeligem Fundament.

scite_, Robustheit zentraler Quellen prüfen Für die fünf bis zehn Schlüsselstudien, auf die sich ein Design-Input-Parameter hauptsächlich stützt, lohnt eine Prüfung in scite_: Wird die Studie in der Fachliteratur überwiegend zustimmend zitiert oder gibt es bekannte Widersprüche und Replikationsprobleme? Das verhindert, dass ihr eine Studie als Goldstandard behandelt, die in der Community als methodisch schwach gilt.

Zusammenfassung: Wann welcher Ansatz

• Erste Literaturrecherche für ein neues Thema, Budget begrenzt → Rayyan (kostenlos) + Elicit (Basic für Orientierung)
• Etablierter Prozess, Review muss Benannter Stelle Stand halten → DistillerSR (Enterprise) + klinischer Experte
• Synthese der validierten Extrakte in Anforderungsdokument → Claude oder ChatGPT mit geprüfter Extraktionstabelle als Input
• Qualitätsprüfung der Kernquellen → scite_

Datenschutz und Datenhaltung

Das Thema ist in der Medizintechnik besonders komplex, weil sich zwei Compliance-Anforderungen überschneiden: DSGVO (für personenbezogene Daten) und die regulatorische Anforderung nach auditierter Dokumentation aller Prozessschritte.

Was typischerweise verarbeitet wird: Bibliografische Metadaten und Abstracts aus öffentlichen Fachdatenbanken. Das sind keine personenbezogenen Daten im DSGVO-Sinne, die Herausforderung liegt woanders.

Was vermieden werden sollte: Unveröffentlichte Studienprotokolle, interne Pre-Submission-Daten, vertrauliche klinische Daten aus eigenen Studien. Sobald ihr solche Daten in externe Cloud-Tools ladet, entsteht eine Datenschutz- und möglicherweise eine Geheimhaltungsverpflichtung.

Tool-Einordnung:

• Rayyan, Elicit, Covidence, DistillerSR: alle US-gehostet. Für öffentliche Literaturdaten aus PubMed/Embase von den meisten Teams toleriert, aber mit dem Datenschutzbeauftragten dokumentieren. AVV ist bei den meisten Anbietern für Enterprise-/Institutional-Pläne erhältlich.
• Claude und ChatGPT: Consumer-Zugänge hostet in den USA. Für Enterprise-Zugänge über AWS Bedrock (Frankfurt, EU-Region) oder Azure OpenAI (EU-Region) ist eine DSGVO-konforme Verarbeitung realisierbar, und für regulatorisch relevante Synthesen die sauberere Option.

Praktische Empfehlung: Schreibt in eure SOP für den KI-gestützten Literaturreview explizit rein, welche Datenkategorien in welchen Tools verarbeitet werden dürfen. Ein Satz wie „Öffentliche bibliografische Daten und Abstracts aus Fachdatenbanken dürfen in [Tool X] verarbeitet werden; unveröffentlichte interne Studienprotokolle verbleiben im internen QMS-System” verhindert Compliance-Lücken und ist bei einem Audit direkt nachweisbar.

Was es kostet, realistisch gerechnet

Tool-Kosten (jährlich)

• Rayyan: kostenlos (bis 3 Reviews) oder 8,33 USD/Sitz/Monat im Advanced-Plan (PICO-Extraktion via KI)
• Elicit Pro: 49 USD/Monat (ca. 590 USD/Jahr), ein Nutzer
• Covidence: 339 USD/Jahr (1 Review), unbegrenzte Reviewer
• DistillerSR: Preis auf Anfrage, Enterprise-Budget, für Einzelprojekte kaum wirtschaftlich
• Claude Pro oder ChatGPT Plus: 20–25 USD/Monat für die Syntheseschritte

Realistisches Setup für ein KMU mit zwei bis vier Literaturreviews pro Jahr: 1.500–3.000 € Toolkosten/Jahr plus Einrichtung und Validierungsaufwand.

Einmalige Einrichtungskosten

• QMS-Validierung der Tools (Risikoklassifizierung, Eignungsbewertung, Prozessvalidierung): 4–10 Arbeitstage intern
• SOP-Erstellung für den KI-gestützten Review-Workflow: 2–4 Arbeitstage
• Schulung des Teams: 1–2 Tage
• Bei externer Unterstützung durch einen RA-Berater: zusätzlich 3.000–8.000 € Einmalaufwand

Was du dagegenrechnen kannst Ein erfahrener Clinical Evidence Specialist kostet im deutschen MedTech-Markt laut Gehaltskompass (2024) durchschnittlich 65.000–85.000 € brutto im Jahr, entsprechend 40–55 € Stundenlohn. Wenn KI-gestütztes Screening fünf Arbeitstage bei einer Literatursynthese einspart, entspricht das 1.600–2.200 € pro Projekt in eingesparten Arbeitskosten. Bei vier Projekten pro Jahr: 6.400–8.800 €, genug, um die Toolkosten zu rechtfertigen. In der Praxis ist diese Rechnung aber selten sauber messbar, weil der Clinical Specialist die eingesparte Zeit meist sofort für die nächste Aufgabe nutzt, nicht für dokumentierte Effizienz-Reports.

Ehrliche Einschätzung: KI-gestützte Literatursynthese rechtfertigt sich nicht durch direkte Kosteneinsparung. Sie rechtfertigt sich durch bessere Qualität (weniger Rückfragen der Benannten Stelle), kürzere Time-to-Market und höhere Quellenabdeckung. Wer das nicht messen kann, sollte den ROI-Kalkül aus der Begründung herauslassen.

Vier typische Einstiegsfehler

1. Das LLM direkt PubMed durchsuchen lassen, ohne strukturierten Methodennachweis. Wer ChatGPT fragt „Finde mir alle relevanten Studien zur Sensitivität von Pulsoximetern bei Herzinsuffizienz-Patienten”, bekommt eine Liste. Aber diese Liste ist kein systematischer Review. Es gibt keine reproduzierbare Suchstrategie, kein PRISMA-Flussdiagramm, keine Dokumentation der Ausschlusskriterien. Das Ergebnis ist für regulatorische Design-Input-Belege unbrauchbar. Schlimmer noch: Studien, die JMIR (2024) zufolge in 28,6–91,3 % der Fälle durch LLMs halluziniert werden, klingen plausibel, und werden ohne Verifizierung ins Anforderungsdokument übernommen. Lösung: Erst strukturierte Datenbanksuche, dann KI für Screening und Extraktion.

2. Die Tool-Validierung im QMS vergessen. In einem ISO-13485-zertifizierten QMS ist Software, die in qualitätsrelevanten Prozessen eingesetzt wird, risikobasiert zu bewerten und dokumentiert zu qualifizieren. Ein Screening-Tool, das bestimmt, welche Studien in die Evidenzbasis einfließen, ist ein solcher Prozess. Wenn der Auditor fragt, auf welcher Basis ihr Rayyan oder Elicit als geeignet bewertet habt, ist „wir haben es einfach benutzt” keine akzeptable Antwort. Lösung: Vor dem Produktivstart eine einfache Eignungsbewertung dokumentieren: Was macht das Tool? Welches Risiko entsteht, wenn es falsch priorisiert? Wie werden Entscheidungen durch den Reviewer verifiziert?

3. Den Expertenvorbehalt unterschätzen, und die falsche Person validieren lassen. KI extrahiert Performance-Werte aus Studien. Aber ob ein Wert aus einer pädiatrischen Studie auf erwachsene Patienten übertragbar ist, ob eine Studie aus 2012 noch dem aktuellen Stand der Technik entspricht, ob die Patientenpopulation mit der Zweckbestimmung des eigenen Produkts vergleichbar ist, das sind klinische Einschätzungen, keine Extraktionsaufgaben. Sie gehören zu einem Arzt, einem Clinical Affairs-Manager mit klinischem Hintergrund, oder einem spezialisierten Consultant. Wer stattdessen einen R&D-Ingenieur die KI-Extrakte absegnen lässt, hat zwar einen Stempel, aber keine regulatorisch belastbare Validierung.

4. Einstieg mit zu vielen Datenbanken auf einmal. MEDDEV 2.7/1 Rev. 4 nennt PubMed und Embase als Mindestanforderung. Wer für den ersten Piloten gleichzeitig noch Scopus, Web of Science, Cochrane und drei klinische Trial-Register durchsucht, erhöht die Treffermenge exponentiell, und den Screeningaufwand entsprechend. Sinnvoller: Mit PubMed + Embase starten, den Workflow validieren, dann erweitern.

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

Der häufigste Irrtum: Das Team denkt, KI-gestütztes Literaturscreening sei ein Tool-Problem. Man kauft Rayyan oder Elicit, richtet es ein, lädt die Treffer hoch, und dann läuft es. Tut es nicht.

Was wirklich passiert:

Die ersten Wochen: Das Team freut sich über die KI-Priorisierung. Dann merkt jemand, dass die Inklusions- und Exklusionskriterien nicht klar genug definiert wurden, die KI sortiert Grenzfälle nach einer Logik, die das Team nicht nachvollziehen kann. Ein halbtägiges Alignment-Meeting ist nötig. Danach sind die Kriterien präziser als vorher.

Nach zwei bis drei Reviews: Das Screening wird routiniert. Aber die Datenextraktion dauert immer noch lange, weil die Extraktionsformulare nicht auf die Design-Input-Parameter des Projekts zugeschnitten sind. Ein Template-Review spart hier Zeit.

Nach sechs bis zwölf Monaten: Das erste Audit. Der Auditor will wissen, wie die KI-Entscheidungen dokumentiert sind. Wenn die SOP das nicht klar regelt, gibt es eine Abweichung, keine kritische, aber eine unnötige. Lösung: Vor dem Audit die SOP einmal durch den Auditor-Blick lesen.

Was sich ändert: Die Qualität der Design-Input-Dokumentation verbessert sich, weil die Quellenabdeckung systematischer ist. Rückfragen der Benannten Stelle zu „unzureichender Literaturbelege” werden seltener. Das ist der echte ROI, schwer in Euro ausdrückbar, aber für Teams, die diesen Schritt gemacht haben, klar spürbar.

Was sich nicht ändert: Der Aufwand für klinische Bewertung. Der Zeitdruck in frühen Entwicklungsphasen. Die grundsätzliche Komplexität der MDR-Anforderungen. Wenn jemand KI als Abkürzung durch regulatorische Anforderungen verkauft, ist das eine fehlerhafte Erwartungssteuerung.

Realistischer Zeitplan mit Risikohinweisen

Realistischer Gesamtzeithorizont: 14–16 Wochen bis zum validierten Produktivbetrieb. Wer in sechs Wochen fertig sein will, muss entweder auf das QMS-Validierungsprotokoll verzichten (nicht empfehlenswert in einem ISO-13485-Umfeld) oder auf externe Beratung setzen, die das parallel aufbaut.

Häufige Einwände, und was dahintersteckt

„KI halluziniert Quellen, das können wir für regulatorische Dokumente nicht nutzen.” Richtig und falsch zugleich. Generative KI (ChatGPT, Claude) halluziniert Quellen, wenn sie direkt nach Literatur gefragt wird, das ist belegt (JMIR, 2024: 28,6–91,3 % Halluzinierungsrate bei systematischen Reviews). Aber das ist nicht die Verwendung, die hier empfohlen wird. Die Datenbanksuche läuft in PubMed und Embase. Das KI-Tool screent und extrahiert aus echten, importierten Paper-Metadaten, keine Erfindung von Quellen, sondern Strukturierung von vorhandenen. Die Syntheseschritte mit einem LLM laufen auf einer vorab validierten Extraktionstabelle, nicht auf freier Generierung. Der Einwand trifft einen echten Fallstrick, aber den falschen Einsatz, nicht den empfohlenen.

„Wir haben zu wenig Volumen für die Toolinvestition.” Bei einem oder zwei Literatursynthesen pro Jahr ist das Argument valide: Der Einrichtungsaufwand amortisiert sich kaum. In diesem Fall ist eine externe CRO (Contract Research Organization) oder ein Clinical-Affairs-Berater mit bestehender DistillerSR-Lizenz die sinnvollere Option. Du bezahlst für die Ergebnisse, nicht für die Toolinfrastruktur.

„Unsere Benannte Stelle akzeptiert keine KI-unterstützten Reviews.” Das ist bisher in keiner öffentlich zugänglichen Guidance von Benannten Stellen oder der EU-Kommission festgelegt. Was akzeptiert werden muss, ist ein methodisch sauberer, reproduzierbarer und dokumentierter Prozess, das KI-Tool ist dabei Hilfsmittel, kein Entscheider. Wer im Methodenabschnitt des Literaturnachweises transparent dokumentiert, welche Tools zu welchem Zweck eingesetzt wurden, steht auf solidem Boden. Was nicht akzeptiert wird: KI als einzige Entscheidungsquelle ohne menschliche Validierung.

Woran du merkst, dass das zu dir passt

• Dein R&D-Team führt mehr als zwei Literatursynthesen pro Jahr durch, um Design Inputs klinisch zu belegen
• Die Rückmeldungen eurer Benannten Stelle enthalten wiederkehrend Hinweise auf unvollständige Literaturbelege
• Ihr habt einen Clinical Evidence Specialist oder Clinical Affairs-Manager im Team (oder guten Zugang zu einem Consultant), der die KI-Ergebnisse validieren kann
• Euer QMS ist auf ISO 13485 zertifiziert und ihr habt Kapazität, neue Software-Tools risikobasiert zu bewerten
• Ihr entwickelt Produkte in mehreren Indikationsbereichen oder plant Produkterweiterungen, für die neue Literaturnachweise nötig werden

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

1. Du entwickelst euer erstes Medizinprodukt ohne etablierten Systematic-Review-Prozess. Wer noch nie einen PRISMA-konformen Literaturreview durchgeführt hat, sollte nicht mit KI-Assistenz starten. Die KI hilft bei der Effizienz eines Prozesses, den man verstehen muss, nicht beim Erlernen des Prozesses. Zuerst manuell den Review-Workflow aufbauen, dann automatisieren.

2. Kein klinischer Experte im oder nahe dem Team. KI extrahiert Zahlenwerte. Ob ein Performance-Wert aus einer Studie mit gesunden Erwachsenen auf deine Zielpopulation (z.B. Patienten mit Komorbiditäten) übertragbar ist, entscheidet ein Arzt oder ein Clinical Affairs-Spezialist, kein Algorithmus. Ohne diesen Schritt sind die Design Inputs regulatorisch nicht belastbar.

3. Weniger als zwei Literatursynthesen pro Jahr, kein QMS-Validierungsbudget. Der Einrichtungsaufwand, SOP, Eignungsbewertung, Pilotvalidierung, kostet intern Tage, extern mehrere Tausend Euro. Bei einem einzelnen Literaturreview im Jahr ist eine externe CRO mit bestehender Toolinfrastruktur wirtschaftlicher als der eigene Aufbau.

Das kannst du heute noch tun

Melde dich kostenlos bei Rayyan an und führe eine Testsuche für ein Design-Input-Thema durch, das ihr gerade bearbeitet oder bearbeitet habt. Exportiere die Treffer aus PubMed als NBIB-Datei, lade sie in Rayyan hoch und definiere drei bis fünf Inklusions- und Exklusionskriterien. Screene 50 Abstracts manuell. Dann aktiviere das KI-Scoring und schau, wie Rayyan die verbleibenden Papers priorisiert.

Das dauert einen halben Tag. Was du danach weißt: ob der Ansatz für euer Thema funktioniert, wie viele Treffer eine typische Suche erzeugt, und wie gut eure Inklusions-/Exklusionskriterien für die KI-Unterstützung formuliert sein müssen.

Für den Syntheseschritt: Nutze den folgenden Prompt mit einem der validierten Extrakte aus eurem Review.

Quellen & Methodik

• LLM-Halluzinierungsraten in systematischen Reviews: Syriani et al., „Hallucination Rates and Reference Accuracy of ChatGPT and Bard for Systematic Reviews”, Journal of Medical Internet Research 2024; 26:e53164. doi:10.2196/53164. Halluzinierungsraten 28,6–91,3 % je Modell und Fragestellung; GPT-3.5 produzierte 39,6 % nicht existierende Referenzen.
• DistillerSR-Validierungsdaten (AI Rerank): DistillerSR / Evidence Partners, „AI Rerank Performance Validation Report 2024”, medianer Screeningaufwand um 47 % reduziert bei 95 % Recall (10 validierte Reviews); publiziert auf www.distillersr.com (Stand Mai 2026).
• Screening-Zeitersparnis 35–80 %: DistillerSR, „Medical Device CER and PER Program Management” (White Paper 2021); im Text zitiert als erfahrungsgemäße Bandbreite aus Nutzerdaten.
• MEDDEV 2.7/1 Revision 4: Europäische Kommission, „MEDDEV 2.7.1 Revision 4, Guidelines on Medical Devices: Clinical Evaluation” (Juli 2016). Zitiert für PICO-Framework, Datenbankminimum (PubMed + Embase) und PRISMA-Anforderungen.
• MDR 2017/745 Anhang I und Anhang XIV: Verordnung (EU) 2017/745 des Europäischen Parlaments und des Rates über Medizinprodukte. Zitiert für GSPR-Anforderungen (Art. 61, Anh. I) und PMCF-Verpflichtungen (Anh. XIV).
• ISO 14971:2019: Medizinprodukte, Anwendung des Risikomanagements auf Medizinprodukte. Zitiert für Hazard-Identification-Anforderung aus Literaturdaten.
• Gehaltskompass 2024 (Clinical Evidence Specialist): Stepstone/Gehalt.de, Gehaltsreport Medizintechnik, Stand 2024. Durchschnittliches Bruttojahresgehalt Clinical Affairs 65.000–85.000 € (Deutschland, erfahrungsgemäße Bandbreite für 3–8 Jahre Berufserfahrung).
• Rayyan-Preismodell: Rayyan.ai, Tarife Stand Mai 2026. Free-Plan (3 Reviews, 2 Reviewer); Advanced 8,33 USD/Sitz/Monat jährlich mit PICO-Extraktion via KI.
• Elicit-Preismodell: Elicit.com, Tarife Stand Mai 2026. Pro 49 USD/Monat (Jahresabo), Systematic-Review-Workflow bis 5.000 Paper.

Du willst einschätzen, ob euer aktueller Design-Input-Prozess von KI-gestützter Literatursynthese profitieren würde, oder erst das methodische Fundament stärken solltet? Meld dich für ein kurzes Gespräch, das klärt das meistens in einer Stunde.