Fünf SaMD-Muster für Pharma-IT

Software as a Medical Device (SaMD) bezeichnet Software, die selbst einen medizinischen Zweck erfüllt, etwa Diagnose, Therapieunterstützung oder patientenbezogene Überwachung. SaMD unterliegt in der EU der Medical Device Regulation (MDR) und in den USA den einschlägigen FDA-Pfaden für Medizinprodukte. Pharma-IT-Systeme in Herstellung, Qualitätssicherung oder Labor sind etwas anderes: Sie stützen GMP-Prozesse, sind aber nicht automatisch Medizinprodukte.

Der Vergleich lohnt trotzdem. MedTech hat für Software mehrere methodische Fragen früher operationalisiert: Klassifizierung, Software-Lifecycle, geplante Änderungen, Feldbeobachtung und technische Dokumentation. Pharma-Hersteller können diese Muster prüfen, wenn sie KI-Systeme in GxP-Prozesse bringen. Die Übernahme bleibt aber methodisch, nicht regulatorisch.

Grenzen zuerst

Die Grenze zwischen SaMD und Pharma-IT ist fachlich wichtig. SaMD wirkt auf Diagnose, Therapie oder Überwachung einzelner Patienten. Pharma-IT sichert Herstell- und Qualitätsprozesse, die mittelbar die Patientensicherheit beeinflussen. Beide Welten arbeiten mit Software-Risiken, aber sie adressieren unterschiedliche Rechtsregime.

MDR-Klassifizierung, IEC-62304-Safety-Class und Annex-22-Scope-Prüfung sind deshalb keine austauschbaren Skalen. MDR Rule 11 ordnet Medizinproduktsoftware nach Zweck und möglichem Schaden ein. IEC 62304 klassifiziert Software nach möglichem Beitrag zu gefährlichen Situationen. Annex 22 betrachtet KI/ML-Modelle in kritischen GMP-Anwendungen über intended use, Testdaten, Explainability, Confidence und Betriebskontrolle. Die Logik ist verwandt, der regulatorische Zielpunkt ist verschieden.

Ein Pharma-Hersteller kann MedTech-Muster nutzen, um die eigene Dokumentation zu verbessern. Er kann daraus keine MDR-Konformität ableiten und keine GMP-Pflicht ersetzen.

Muster 1: Klassifizierung vor Lösung

MedTech beginnt bei Software mit Zweckbestimmung und Risikoklasse. MDCG 2019-11 hilft bei der Frage, ob Software unter MDR oder IVDR fällt und wie sie einzuordnen ist. IEC 62304 ergänzt die Safety Class A, B oder C, abhängig vom möglichen Beitrag der Software zu einer gefährlichen Situation.

Für Pharma-IT ist die übertragbare Idee nicht die MDR-Klasse. Übertragbar ist die Reihenfolge: erst intended use, dann Risiko, dann Nachweistiefe. Eine KI-Anwendung zur SOP-Recherche, ein Modell zur Abweichungsvorbewertung und ein Computer-Vision-System in der visuellen Inspektion dürfen nicht mit derselben Validierungstiefe starten.

Das Mindestartefakt ist eine Klassifizierungsnotiz pro KI-Use-Case. Sie enthält intended use, GxP-Prozess, Datenklasse, menschliche Kontrolle, mögliche Fehlentscheidung, Annex-22-Scope-Prüfung und daraus abgeleitete Nachweistiefe. Die Notiz gehört in das AI Use Case Inventory und später in das integrierte Validierungsdossier.

Muster 2: PCCP als Change-Control-Vorlage

Der Predetermined Change Control Plan (PCCP) ist ein FDA-Konzept für AI-enabled devices. Die Final Guidance vom 03.12.2024, die den Draft von April 2023 ersetzt und für alle AI-enabled Device Software Functions gilt, beschreibt Empfehlungen für geplante Änderungen, die Methodik zur Entwicklung, Validierung und Implementierung dieser Änderungen sowie die Bewertung ihrer Auswirkungen. Die FDA prüft den PCCP als Teil einer Marketing Submission, damit beschriebene Änderungen nicht jeweils eine neue Einreichung auslösen.

Für Pharma-KI entsteht daraus keine EU-Pflicht. Annex 22 liegt zum Veröffentlichungsdatum dieses Beitrags am 23.04.2026 als EU-Kommissions-Konsultationsentwurf vom 7. Juli 2025 vor. Der Entwurf deckt dynamische Modelle in kritischen GMP-Anwendungen nicht ab. PCCP-Logik kann deshalb nur als methodische Vorlage für Change-Control-Denken dienen, nicht als Freibrief für adaptive Modelle im kritischen GMP-Prozess.

Übertragbar sind drei Bausteine:

1. Änderungsgrenzen. Welche Modelländerungen, Datenupdates oder Parameteranpassungen sind innerhalb des freigegebenen Rahmens zulässig?
2. Änderungsmethodik. Wie werden Entwicklung, Test, Review, Freigabe und Rollback einer Änderung durchgeführt?
3. Auswirkungsbewertung. Welche Performance-, Datenintegritäts- und Prozessrisiken entstehen durch die Änderung?

In der Pharma-IT wird daraus kein Marketing-Submission-Artefakt, sondern ein Change-Control-Anhang für klar begrenzte Modell- und Anbieteränderungen. Er verweist auf Validierungsstrategie, Monitoring, Anbieterunterlagen und Revalidierungsentscheidung.

Muster 3: IEC 62304 für eigene Entwicklung

IEC 62304 beschreibt Software-Lifecycle-Prozesse für Medizinproduktsoftware. Der Nutzen für Pharma-IT liegt nicht darin, die Norm allgemein einzuführen. Relevant wird sie dort, wo Pharma-Unternehmen eigene Software entwickeln, KI-Modelle trainieren, Custom-Integrationen bauen oder Anbieterfunktionen wesentlich erweitern.

GAMP 5 betrachtet stark die Anwenderperspektive: intended use, Lieferantenbewertung, Validierung, Betrieb und Change Control. IEC 62304 betrachtet stärker die Herstellerperspektive: Entwicklungsplanung, Anforderungen, Architektur, Implementierung, Integrationstest, Release, Wartung, Konfigurationsmanagement und Problem Resolution.

Diese Herstellerperspektive fehlt in manchen Pharma-IT-Projekten. Ein intern trainiertes Modell für Labortrend-Analysen oder ein selbst gebauter KI-Service für Dokumentenklassifikation braucht nicht nur Validierung am Ende. Es braucht eine kontrollierte Entwicklungsakte. IEC 62304 kann dafür als Strukturvorlage dienen, auch wenn das System kein Medizinprodukt ist.

Muster 4: PMS als Monitoring-Vorlage

Post-Market Surveillance (PMS) ist im MDR-System die Beobachtung eines Medizinprodukts nach dem Inverkehrbringen. Dazu gehören Rückmeldungen aus dem Feld, Vigilanz, Trendbeobachtung, Post-Market Clinical Follow-up und je nach Klasse Berichte wie PMS Report oder Periodic Safety Update Report.

Für Pharma-IT passt keine Gleichsetzung mit Continued Process Verification. Besser ist die Übertragung einzelner Arbeitsweisen auf den Betrieb computergestützter Systeme: Monitoring, Periodic Evaluation, Incident Management, Deviation Management, CAPA, Change Control und Lieferantenreview.

Bei KI-Systemen sind diese Bausteine besonders relevant. Modellleistung kann durch neue Daten, geänderte Prozesse, andere Messgeräte, neue Produktvarianten oder Anbieterupdates abweichen. Ein Monitoring-Konzept legt Kennzahlen, Schwellenwerte, Review-Frequenz, Verantwortlichkeiten und Eskalationswege fest. PMS-Templates aus MedTech können helfen, diese Struktur zu entwerfen. Die GxP-Entscheidung bleibt im eigenen Quality Management System.

Muster 5: Technische Dokumentation als Anbieter-Evidenz

MedTech-Hersteller müssen technische Dokumentation führen, die Zweckbestimmung, Risikomanagement, Entwicklung, Verifikation, Validierung, klinische Bewertung, PMS und Änderungen nachvollziehbar macht. Benannte Stellen prüfen diese Dokumentation im MDR-System, soweit eine Konformitätsbewertung mit Benannter Stelle erforderlich ist.

Pharma-Anwender prüfen Softwareanbieter anders. Es gibt keine Benannte Stelle, die den Cloud- oder KI-Anbieter für den Pharma-Anwender zertifiziert. Trotzdem ist die MedTech-Logik hilfreich: Anbieter-Evidenz muss strukturiert, aktuell, scope-bezogen und prüfbar sein.

Für Pharma-IT bedeutet das: Vendor Documentation wird gegen das eigene Risiko gemappt, nicht nur gesammelt. Relevante Unterlagen sind Entwicklungsprozess, Testabdeckung, Release Notes, Known Issues, Security Reports, Subprozessoren, Supportmodell, Datenverarbeitung, Modellinformationen und Change-Kommunikation. Bei KI-Systemen kommen Trainings- und Validierungsdaten, Performance-Metriken, bekannte Grenzen, Bias-/Drift-Bewertung und Update-Strategie hinzu.

Die methodische Lektion lautet: Anbieter-Evidenz braucht eine Prüflogik. Eine Dateiablage ohne Scope-Bewertung trägt im Audit nicht.

Grenzen der Übertragung

Vier Grenzen bleiben für Pharma-Hersteller zentral.

Rechtsregime. MDR und FDA-Device-Pfade regulieren Medizinprodukte. GMP, Annex 11, GAMP 5, EU AI Act und künftig Annex 22 regulieren andere Aspekte. Ein MedTech-Artefakt kann inspirieren, aber keine Pharma-Pflicht ersetzen.

Adressat. MedTech-Regeln richten sich an Hersteller eines Produkts. Pharma-IT-Regeln treffen bei eingekauften Systemen den Anwender im GxP-Prozess. Die Verantwortung liegt anders, insbesondere bei SaaS und Cloud.

Patientenbezug. SaMD kann unmittelbar Diagnose oder Therapie beeinflussen. Pharma-IT wirkt meist über Herstell- und Qualitätsprozesse. Der Risikopfad ist anders zu begründen.

Behördenlogik. Benannte Stellen und FDA-Submissions folgen anderen Abläufen als GMP-Inspektionen. Die Auditfrage in Pharma lautet nicht, ob ein SaMD-Prozess eingehalten wurde, sondern ob der GxP-Prozess kontrolliert ist.

Diese Grenzen machen die Analogie nicht wertlos. Sie verhindern nur, dass aus einer methodischen Inspiration eine falsche regulatorische Behauptung wird.

Anschluss für Pharma-IT

Ein sinnvoller Einstieg ist ein Cross-Reference-Mapping. Es ordnet je KI-Use-Case zu, welche MedTech-Muster als Vorlage dienen und welches Pharma-Artefakt daraus entsteht.

Diese Tabelle reicht als Startpunkt. Danach entscheidet der konkrete Use Case, welche Muster relevant sind. Eine KI-gestützte SOP-Recherche braucht kein PCCP. Bei einem Bildauswertungssystem in der visuellen Inspektion kann PCCP-Logik als Vorlage für geplante, kontrollierte Modelländerungen dienen, sofern die Annex-22-Grenzen für kritische GMP-Anwendungen beachtet werden.