Predictive Maintenance für Medizingeräte: Was FDA 21 CFR Part 11 und der EU AI Act wirklich von Ihrer Architektur verlangen

Ein System für Predictive Maintenance an Medizingeräten kann die IT-Sicherheitsprüfung Ihres Krankenhauses bestehen und trotzdem durch ein 21-CFR-Part-11-Audit fallen. Der Grund: Das Retraining des ML-Modells wurde nie als Änderung eines elektronischen Datensatzes protokolliert. Genau diese Lücke trifft die meisten Projekte rund um 21 CFR Part 11 Predictive Maintenance erst dann, wenn ein Notified Body oder ein FDA-Inspektor im falschen Meeting die richtige Frage stellt.

Wenn Sie ein System für vorausschauende Wartung von CT-Scannern, MRT-Geräten, Infusionspumpen, Beatmungsgeräten oder robotischen Chirurgiesystemen bauen oder einkaufen und dabei in den USA, in der EU oder in beiden Märkten tätig sind, dann muss Ihre Architektur genau das erfüllen, was hier beschrieben ist. Die Pflichten aus 21 CFR Part 11 Predictive Maintenance erst spät in der Umsetzung als Häkchen nachzurüsten, ist der teuerste Planungsfehler, den wir in dieser Projektkategorie sehen. Auf europäischer Seite gilt dasselbe: Der AI Act für Medizinprodukte wird oft als juristische Nacharbeit behandelt statt als Eingangsgröße der Architektur.

YMYL-Hinweis: Dieser Beitrag ist technische und architektonische Orientierung auf Basis öffentlich zugänglicher Regulierungstexte. Er ist keine Rechtsberatung. Die regulatorische Einordnung – Part-11-Geltungsbereich, MDSW-Status, Hochrisiko-Klassifizierung – hängt von Ihrem konkreten Produkt, dessen Zweckbestimmung und der Jurisdiktion ab und sollte vor der endgültigen Architekturfreigabe mit Regulatory Counsel oder Ihrem Notified Body bestätigt werden.

• Ein PdM-System, das patientennahe Medizingeräte überwacht, fällt sehr wahrscheinlich unter Hochrisiko-KI gemäß Anhang III des EU AI Act. Erforderlich sind Konformitätsbewertung, technische Dokumentation nach Anhang IV und CE-Kennzeichnung vor dem 2. August 2026.
• Die Anforderungen von 21 CFR Part 11 an Machine Learning greifen, sobald das PdM-System elektronische Datensätze erzeugt, die in regulierten Prozessen verwendet werden – bei Kalibrierung, Wartung oder Produktion. Retraining-Ereignisse von Modellen sind „Änderungsdatensätze“ nach §11.10(e) und brauchen vollständige Audit Trails.
• Die am häufigsten übersehene Part-11-Pflicht bei ML-Systemen: Der Audit Trail muss nicht nur festhalten, wer Daten geändert hat, sondern auch den vorherigen Wert, den Grund der Änderung und den Zeitstempel – und zwar auf Ebene einzelner Sensorwerte und Modellparameter.
• Artikel 14 des EU AI Act verlangt, dass Hochrisiko-KI-Systeme menschliche Aufsicht unterstützen. Architektonisch heißt das: ein explizit ansprechbarer Override- und Pause-Endpunkt, den Ihr CMMS oder ERP aufrufen kann – kein Dashboard-Button, den das Wartungspersonal umgehen kann.
• Die FDA verlangt Validierung vor dem Rollout (CSV: IQ/OQ/PQ), der EU AI Act laufendes Post-Market-Monitoring (Artikel 72). Das sind zwei unterschiedliche Paradigmen, und Compliance bei Predictive Maintenance für Medizingeräte bedeutet, dass Ihre Architektur beide gleichzeitig erfüllen muss.

Regulatorischer Geltungsbereich: Welche Regeln greifen bei Compliance bei Predictive Maintenance für Medizingeräte?

Nicht jedes PdM-Rollout löst jede Regulierung aus. Der Geltungsbereich hängt davon ab, was das System ausgibt, ob diese Ausgabe in einen regulierten Prozess einfließt und ob das überwachte Gerät selbst ein Medizinprodukt ist. Die Einordnung in eine der beiden Richtungen falsch zu treffen – zu viel für Regeln zu bauen, die nicht greifen, oder solche zu übersehen, die greifen – ist der kostspieligste Fehler in dieser Kategorie.

Wann FDA 21 CFR Part 11 greift

Der Auslöser ist im Prinzip klar und in der Praxis unübersichtlich: Die Pflichten greifen, sobald das PdM-System elektronische Datensätze erzeugt, die eine Predicate Rule verlangt – etwa Wartungsdatensätze nach 21 CFR Part 820 oder Datensätze zu pharmazeutischen Anlagen nach 21 CFR Part 211. Liegen die Wartungsdatensätze ausschließlich im CMMS und das PdM-Werkzeug „empfiehlt“ lediglich, erreicht Part 11 die PdM-Schicht möglicherweise nicht direkt. Erzeugt das PdM-System selbst Datensätze, die später in regulatorischen Einreichungen oder in einer Device History Record auftauchen, zieht §11.1(b) es in den Geltungsbereich.

Der praktische Test: Würde ein FDA-Inspektor diesen Datensatz als Teil einer Device History File prüfen? Wenn ja, befinden Sie sich im Part-11-Bereich, einschließlich der Pflichten zu Predicate Rule und elektronischer Signatur. Teams, die diesen Scoping-Schritt überspringen, sind meist dieselben, die Kontrollen für 21 CFR Part 11 Predictive Maintenance nach einem gescheiterten Audit nachrüsten – was deutlich mehr kostet, als sie von Anfang an mitzuplanen.

Wann die Hochrisiko-Klassifizierung des EU AI Act greift

Der Klassifizierungspfad läuft über das überwachte Gerät, nicht über die PdM-Software isoliert. Überwacht ein PdM-System nach Verordnung (EU) 2024/1689 Anlagen, die selbst Medizinprodukte sind – ein MRT, ein CT-Scanner, ein Beatmungsgerät oder eine Infusionspumpe unter der EU-MDR 2017/745 –, kann das PdM-System als Sicherheitsbauteil nach Anhang III, Punkt 5(a) gelten und landet damit über Artikel 6 in der Kategorie Hochrisiko-KI. Das ist ein Kernfall von Hochrisiko-KI im Gesundheitswesen, und er bringt eine harte Frist mit: volle Konformität für Hochrisiko-KI-Systeme bis zum 2. August 2026. Ist das Gerät bereits unter der EU-MDR CE-gekennzeichnet, überlagert der AI Act diese Zertifizierung, statt einen völlig getrennten Compliance-Pfad zu verlangen – aufgehoben wird sie damit aber nicht. Genau hier hört der AI Act für Medizinprodukte auf, ein Thema für Regulatory Affairs zu sein, und wird zur Architekturentscheidung.

Wenn die EU-MDR ins Spiel kommt: die MDSW-Frage

Bevor die Klassifizierung nach dem EU AI Act überhaupt relevant wird, brauchen Sie eine Antwort auf die MDCG 2019-16 – MDSW-Qualifizierung unter der EU-MDR 2017/745. Ist die PdM-Ausgabe Entscheidungsunterstützung, ist sie für sich genommen wahrscheinlich keine Medical Device Software. Kann die Ausgabe eine automatische Abschaltung oder einen Eingriff am Gerät während der Patientenanwendung auslösen, handelt es sich wahrscheinlich um MDSW und damit um eine Einordnung nach Regel 11 (typischerweise Klasse IIa oder IIb) – mit Prüfung durch einen Notified Body und Pflichten aus IEC 62304 zum Software-Lebenszyklus. Das ist der Punkt, an dem die Logik der SaMD-Compliance für Medizinprodukte-Software aus dem FDA-Rahmen auf den EU-Regulierungsstapel übertragen wird: Das Zusammenspiel von EU AI Act und EU MDR bedeutet hier: Das eine ersetzt das andere nicht, beide Rahmen koexistieren, statt sich gegenseitig aufzuheben. Die Klassifizierungsfrage zum AI Act für Medizinprodukte zuerst zu klären, verhindert Nacharbeit, weil sie bestimmt, welche Dokumentationspflichten überhaupt gelten.

Unser Team für Beratung rund um Gesundheits-IT führt diese Klassifizierung als erstes Arbeitsergebnis jedes PdM-Projekts mit doppelter Jurisdiktion durch – bevor eine einzige Zeile Compliance-Architektur entsteht.

Was FDA 21 CFR Part 11 wirklich von Ihrer PdM-Architektur verlangt

Part 11 wurde für elektronische Datensätze und Signaturen im Allgemeinen geschrieben, nicht speziell für Machine Learning. Genau deshalb bauen die meisten PdM-Teams zu wenig dafür. Vier Bereiche tragen das praktische Gewicht: Granularität des Audit Trails, Zugriffskontrolle, Computersystemvalidierung und elektronische Signaturen.

Granularität des Audit Trails: was §11.10(e) tatsächlich fordert

FDA 21 CFR §11.10(e) verlangt Audit Trails, die maschinell erzeugt und mit Zeitstempel versehen sind und jede Änderung eines Datensatzes der verantwortlichen Person zuordnen – einschließlich des Änderungsgrunds. Für ein PdM-System bedeutet das: jede Änderung eines Sensorwerts in der Datenbank; jedes Retraining des Modells samt auslösender Person, Modellversion davor und danach sowie Validierungszusammenfassung; jedes Übersteuern eines Alarms durch eine Wartungstechnikerin, mit Person, Zeitpunkt und Begründung; und jeder Kalibrierdatensatz. Das ist der praktische Kern der FDA-Audit-Trail-Anforderungen für ML-Modelle. Architektonisch muss der Audit Log als Append-only-Tabelle, kryptografische Hash-Kette oder gleichwertiger Write-once-Speicher umgesetzt sein. Unter ALCOA+ für Medizinprodukte-Software – Attributable, Legible, Contemporaneous, Original, Accurate, ergänzt um Complete, Consistent, Enduring, Available – bedeutet „Attributable“, dass jeder Datensatz an ein konkretes individuelles Benutzerkonto gebunden ist, nie an ein gemeinsames Service-Konto. Die Aufbewahrung muss die gesamte Nutzungsdauer des Geräts plus zwei Jahre abdecken, passend zu den Anforderungen an Device History Records nach 21 CFR Part 820.

Zugriffskontrolle: warum Service-Konten an Part 11 scheitern

Ein verbreitetes Fehlermuster: Das PdM-System schreibt alle Sensordaten über ein einziges Service-Konto, sodass jeder Datensatz nur „dem System“ zuzuordnen ist und nicht einer Person – ein direkter Verstoß gegen §11.10(d). Die Lösung ist architektonisch: Jeder Mensch, der mit dem System arbeitet, braucht ein eigenes individuelles Benutzerkonto; automatisierte Prozesse wie die ML-Pipeline erhalten ein eigenes Service-Konto, dem der Schreibzugriff auf den Audit Trail selbst entzogen ist. §11.300 regelt dann die Details passwortbasierter Authentifizierung: Passwortrichtlinie, Kontosperrung, Sitzungs-Timeout. Multi-Faktor-Authentifizierung schreibt der Part-11-Text nicht zwingend vor, in der aktuellen FDA-Inspektionspraxis wird sie faktisch aber erwartet.

Computersystemvalidierung für ML-Komponenten

Computersystemvalidierung für Predictive Maintenance folgt der klassischen Struktur IQ/OQ/PQ, doch ML-Komponenten überdehnen ein Modell, das für statische Software gedacht war. Die Installation Qualification bestätigt, dass Infrastruktur, Softwareversionen und Netzwerksicherheit korrekt installiert sind. Die Operational Qualification bestätigt, dass die Alarmgenauigkeit innerhalb validierter Schwellen liegt und Audit Trail sowie Zugriffskontrolle wie spezifiziert funktionieren. Die Performance Qualification bestätigt gleichbleibende Leistung unter echten Produktionsbedingungen. Das ML-spezifische Problem: Klassische Validierung setzt voraus, dass sich die Software nicht selbst verändert – Modell-Retraining ist genau diese Art Veränderung und erfordert dokumentiertes Änderungsmanagement sowie erneute Validierung, bevor eine neue Version in Produktion geht. Der AI/ML SaMD Action Plan der FDA von 2021 führt dafür das Konzept eines vorab festgelegten Änderungskontrollplans ein: Updates innerhalb zuvor definierter Grenzen sind erlaubt, ohne jedes Mal eine vollständige neue Einreichung.

Architektonisch heißt das: Modellversionierung (etwa mit MLflow), eine automatisierte Validierungs-Testsuite, die vor jeder Promotion einer neuen Modellversion läuft, und ein dokumentierter, prüfbarer Freigabe-Workflow, der diese Promotion gatet.

Elektronische Signaturen: wann und in welchem Format

Signaturen sind an bestimmten Entscheidungspunkten im PdM-Ablauf erforderlich: wenn eine Wartungsmaßnahme ein Gerät für den Einsatz freigibt, wenn ein Kalibrierdatensatz genehmigt wird oder wenn eine Validierungszusammenfassung des Modells abgezeichnet wird. FDA 21 CFR §11.50 und §11.70 verlangen, dass die Signatur den ausgeschriebenen Namen, die Rolle, die Bedeutung der Handlung und Datum samt Uhrzeit trägt und einer handschriftlichen Unterschrift funktional gleichwertig ist. Das setzt eine erneute Eingabe von Benutzername und Passwort voraus, nicht ein blankes Häkchen „Genehmigen“. Architektonisch braucht es dafür einen eigenen E-Signatur-Dienst, wobei die Signatur als integraler Bestandteil des elektronischen Datensatzes gespeichert wird und nicht in einer separaten Tabelle.

«In unseren Projekten für Medizinprodukte-Software liegt die häufigste Lücke zwischen einer funktionierenden PdM-Demo und einem Part-11-konformen System nicht am ML-Modell selbst, sondern an der Granularität des Audit Trails für Retraining-Ereignisse – Teams behandeln sie als Betriebsprotokoll statt als regulierten Datensatz. Die Healthcare-Engineering-Teams von Elinext bauen die unveränderliche Audit-Schicht und das Gate für Modellversionierung von Tag eins an als gemeinsam genutzten Dienst, damit Retraining belegbar und prüfbar ist und nicht während eines Audits nachträglich rekonstruiert werden muss. Für Kunden hat das bedeutet, mit fertig aufbereiteten Änderungsnachweisen in FDA-Pre-Submission-Meetings zu gehen, statt sie kurzfristig zusammenzusuchen.»

— Victoria Yaskevich, Healthcare IT Consultant bei Elinext

Was der EU AI Act wirklich von Ihrer PdM-Architektur für Medizingeräte verlangt

Wo es bei Part 11 um Datensätze geht, geht es beim EU AI Act um das Verhalten und die Governance des KI-Systems über seinen gesamten Lebenszyklus. Vier Artikel tragen bei Hochrisiko-KI im Gesundheitswesen das architektonische Gewicht eines PdM-Systems.

Artikel 14: menschliche Aufsicht ist eine API-Anforderung, keine UI-Anforderung

Die architektonische Schlussfolgerung zählt hier mehr als der Gesetzestext: EU AI Act Artikel 14 – menschliche Aufsicht bedeutet nicht Dashboard-Button. Artikel 14(4)(b) verlangt, dass menschliche Bedienpersonen die Ausgabe des KI-Systems verwerfen können. Ein durch eine PdM-Empfehlung ausgelöster Wartungsauftrag braucht deshalb neben „Annehmen“ eine explizite Aktion „Ablehnen“, verfügbar als programmatischer API-Endpunkt, den ein CMMS oder ERP aufrufen kann. Artikel 14(4)(e) verlangt, dass das System durch einen Menschen abgeschaltet werden kann – umzusetzen als Kill Switch auf Ebene der Inferenz-API, nicht nur im Frontend. Override-Ereignisse sollten in das Post-Market-Monitoring nach Artikel 72 zurückfließen: Die Häufigkeit von Overrides ist selbst eine brauchbare Näherungsgröße für die Zuverlässigkeit des Modells.

Artikel 13: Erklärbarkeit ist bei Hochrisiko-KI nicht optional

Nach Artikel 13 muss jede Wartungsempfehlung des Modells einen Konfidenzwert tragen – etwa 87 Prozent Wahrscheinlichkeit für einen Lagerschaden innerhalb von 72 Stunden –, die wichtigsten beitragenden Merkmale über ein Verfahren wie SHAP oder LIME – etwa Vibration bei dreifacher Laufdrehzahl, 40 Prozent über dem 30-Tage-Ausgangswert – sowie einen Hinweis auf veraltete Daten, wenn der relevante Sensor länger nichts gemeldet hat. Diese Erklärbarkeitsschicht gehört in die reguläre Inferenzausgabe, und die Methodik selbst muss in der technischen Dokumentation nach Anhang IV §2(f) beschrieben sein. Dazu gehört eine ausgewiesene Einschränkung: Das System wurde auf einem bestimmten Zeitraum und Gerätebestand trainiert, und die Leistung kann bei Varianten außerhalb dieses Bestands nachlassen.

Artikel 10: Governance der Trainingsdaten

Artikel 10 verlangt dokumentierte Governance der Trainingsdaten: welche Gerätemodelle abgedeckt sind, welcher Zeitraum, welche Sensortypen, wie Ausfallereignisse gelabelt wurden und welche betrieblichen und geografischen Bedingungen abgebildet sind. Hier werden Repräsentativitätslücken zu Compliance-Lücken. Ein Modell, das auf drei CT-Scanner-Modellen trainiert wurde, erfüllt Artikel 10 nicht, wenn es über fünfzehn Modelle hinweg eingesetzt wird. Anhang IV §2(d) verlangt die Dokumentation von Erhebungsmethodik, Aufbereitungsschritten und Ergebnissen der Bias-Bewertung. Architektonisch heißt das: Data-Lineage-Tracking direkt in der Datenpipeline, nicht nachträglich rekonstruiert.

Artikel 72: Post-Market-Monitoring – der Unterschied zur FDA

Bei Artikel 72 weicht der EU AI Act am deutlichsten von der FDA-Denkweise der Validierung vor dem Rollout ab: Er verlangt laufende Überwachung der Inferenzqualität im echten Produktionsbetrieb, nicht nur zum Validierungszeitpunkt. Mindestens gehören dazu die False-Positive-Rate aktiver Wartungsalarme, die Override-Rate der Wartungsteams und die Zeit vom Alarm bis zum bestätigten Ausfall als Frühindikator für die Modellgenauigkeit. Nötig ist dafür eine ML-Monitoring-Pipeline, getrennt vom gewöhnlichen Application Monitoring – eine, die sowohl Data Drift (Verschiebung der Verteilung von Sensorwerten) als auch Concept Drift (nachlassende Modellgenauigkeit gegen aktuelle gelabelte Ereignisse) erkennt. Artikel 73 setzt eine weitere harte Frist: Trägt ein PdM-Versagen zu einem schwerwiegenden Vorfall mit Patientensicherheitsbezug bei, ist er der zuständigen nationalen Marktüberwachungsbehörde innerhalb von 15 Tagen zu melden.

Systeme, die vernetzte klinische Geräte auf diesem Detailniveau überwachen, teilen oft Infrastruktur mit umfassenderen Krankenhaus-Datenplattformen. Dieselben Muster für Datenherkunft und Monitoring greifen in unseren Projekten zur EHR-Software-Entwicklung für klinische Datensätze.

Wo sich FDA 21 CFR Part 11 und der EU AI Act überschneiden – und wo sie kollidieren

Wenn Sie gleichzeitig für den US- und den EU-Markt bauen, ist dieser Abschnitt derjenige, der Ihre Architektur wirklich verändert.

Gemeinsame Anforderungen: einmal bauen

Vier Komponenten erfüllen beide Regime ohne Doppelarbeit und machen das Zusammenspiel von EU AI Act und EU MDR auf Architekturebene konkret: ein unveränderlicher Audit Trail mit Benutzerzuordnung und Zeitstempel, verlangt von §11.10(e) wie von Artikel 72; ein Override-Mechanismus für Menschen, verlangt von der Zugriffslogik nach §11.10(d) wie von der Verwerfbarkeit nach Artikel 14(4)(b); Modellversionierung mit Deployment-Gates, verlangt von der Änderungskontrolle der Validierung wie von den Regeln zur wesentlichen Änderung im EU AI Act; und Data-Lineage-Tracking, verlangt von ALCOA+ für Medizinprodukte-Software wie von der Datengovernance nach Artikel 10. Bauen Sie diese vier einmal richtig, und sie tragen beide Jurisdiktionen.

Der eigentliche Konflikt: Validierung vorab gegen laufendes Monitoring

Die echte Spannung: Die FDA erwartet einen „validierten Zustand“, der zum Zeitpunkt des Rollouts feststeht, während der EU AI Act einen „überwachten Zustand“ erwartet, der sich danach weiterentwickelt, mit erlaubten Updates, solange sie dokumentiert sind. Bei einem Modell, das auf neuen Daten nachtrainiert wird, ist jedes Retraining nach FDA-Logik eine validierungspflichtige Änderung. Nach dem EU AI Act ist es zulässig, solange es innerhalb vorab festgelegter Änderungsgrenzen bleibt und im Post-Market-Monitoring-Bericht dokumentiert wird. Das FDA-Konzept der vorab festgelegten Änderungskontrolle und das Konzept der wesentlichen Änderung im EU AI Act zielen von verschiedenen Seiten auf dasselbe Problem, unterscheiden sich aber in der Umsetzung. Die praktische Auflösung: Definieren Sie die Änderungsgrenzen des Modells im Vorhinein – etwa „Retraining auf neuen Daten innerhalb der ursprünglichen Sensortypen, gleiche Gerätemodelle, Genauigkeitsmetriken innerhalb von ±5 Prozent“. Änderungen innerhalb dieser Grenzen erhalten einen leichteren Validierungspfad; Änderungen darüber hinaus lösen vollständige Neuvalidierung plus eine Bewertung als wesentliche Änderung nach dem EU AI Act aus. Wer die Anforderungen von 21 CFR Part 11 an Machine Learning und die europäische Monitoringpflicht gemeinsam plant, baut diesen Konflikt nicht zweimal.

Jurisdiktionsspezifisch: was jede Behörde allein verlangt

Manche Pflichten überschneiden sich gar nicht. Nur FDA: das Signaturformat nach §11.50, die Dokumentation der Computersystemvalidierung nach GAMP 5 und die FDA-spezifischen Predicate-Rule-Datensätze. Nur EU AI Act: Konformitätsbewertung nach Artikel 43, Registrierung in der EU-Datenbank nach Artikel 49, EU-Konformitätserklärung nach Artikel 48 und ein Post-Market-Monitoring-Plan für den Notified Body – dazu die EUDAMED-Registrierung, wo zusätzlich die EU-MDR gilt. Für EU-MDR-Software heißt das: Die Dokumentationsstränge laufen parallel, nicht alternativ.

Sie planen ein System, das beide Regime erfüllen soll, ohne zwei parallele Compliance-Stacks zu bauen? Unser Team für Entwicklung von Predictive Maintenance Software geht mit Ihnen durch, wo Ihre bestehende Architektur gemeinsame Anforderungen bereits abdeckt und wo nicht.

Compliance-fähige PdM-Architektur für Medizingeräte: die Kernkomponenten

Compliance bei Predictive Maintenance für Medizingeräte löst sich am Ende in sieben konkrete Dienste auf. Bauen Sie diese, und sowohl die Pflichten aus 21 CFR Part 11 Predictive Maintenance als auch die aus dem EU AI Act sind strukturell abgedeckt, statt spät angeflanscht zu werden.

1. Unveränderlicher Audit-Trail-Dienst — ein Append-only-Speicher, etwa eine Event-Sourced-Datenbank oder ein hash-verketteter Log, der jede Sensoränderung, jedes Retraining und jedes Override mit Benutzerzuordnung und Zeitstempel erfasst. Erfüllt §11.10(e) und Artikel 72 gleichzeitig.
2. Rollenbasierte Zugriffskontrolle plus individuelle Benutzerkonten — durchgesetzt über einen Identity Provider wie Keycloak oder Azure AD, ohne gemeinsam genutzte Service-Konten mit Schreibzugriff auf regulierte Datensätze. Adressiert §11.10(d) und §11.300.
3. API für menschliche Aufsicht — ein programmatischer Endpunkt für Annehmen, Ablehnen und Pausieren, aufrufbar durch CMMS- oder ERP-Systeme und nicht nur über die Oberfläche. Setzt Artikel 14(4)(b) und (e) direkt um.
4. Erklärbarkeitsschicht — Merkmalsattribution über SHAP oder LIME samt Konfidenzbewertung, angehängt an jede Inferenzausgabe. Erfüllt die Transparenzanforderungen aus Artikel 13.
5. Modellversionierung plus Deployment-Gate — eine Registry wie MLflow, kombiniert mit automatisierter Validierungssuite und dokumentiertem Freigabe-Workflow vor jeder Promotion. Deckt Änderungskontrolle der Validierung und Nachverfolgung wesentlicher Änderungen nach EU AI Act ab.
6. Pipeline für ML-Performance-Monitoring — eigene Erkennung von Data Drift und Concept Drift, etwa über Evidently AI oder einen eigenen statistischen Monitor, die den Post-Market-Monitoring-Bericht nach Artikel 72 speist.
7. FDA-E-Signatur-Dienst (nur USA) — ein dedizierter Signaturdienst, der ausgeschriebenen Namen, Rolle, Bedeutung der Signatur und Zeitstempel nach §11.50 erfasst und als Teil des elektronischen Datensatzes selbst speichert.

Bei vernetzten Geräten, die Daten an patientenferne Systeme liefern, greifen dieselben Muster wie in unseren Projekten zur Telemedizin-Software-Entwicklung.

«Als die PdM-Plattform eines Kunden in die Prüfung durch den Notified Body unter der EU-MDR ging, war die erste Frage, ob das ML-Modell nach MDCG 2019-16 als MDSW qualifiziert. Die zweite war, ob der Override-Mechanismus in der technischen Dokumentation beschrieben ist und nicht bloß in der Oberfläche existiert. Elinext entwirft Audit Trail, Aufsichts-API und Monitoring-Pipeline deshalb als eine gemeinsame Compliance-Schicht über FDA- und EU-AI-Act-Pflichten hinweg, statt als getrennte Lieferergebnisse je Behörde. Für Kunden hat das weniger Prüfzyklen mit dem Notified Body bedeutet – und eine technische Dokumentation, die schon bei der ersten Einreichung trägt.»

— Victoria Yaskevich, Healthcare IT Consultant bei Elinext

Wichtigste Erkenntnisse: PdM-Architektur für Compliance in zwei Jurisdiktionen

• FDA 21 CFR Part 11 gilt für ein PdM-System, sobald es elektronische Datensätze erzeugt, die eine Predicate Rule verlangt (21 CFR Part 820, 211). Retraining-Ereignisse von Modellen sind „Änderungen“, die Audit Trails mit vorherigem Wert, Grund und Benutzerzuordnung nach §11.10(e) erfordern – der Kern der FDA-Audit-Trail-Anforderungen für ML-Modelle.
• Die Hochrisiko-Klassifizierung des EU AI Act greift voraussichtlich über Anhang III Punkt 5(a), wenn ein PdM-System Medizingeräte überwacht, die unter die EU-MDR 2017/745 fallen. Frist für volle Konformität: 2. August 2026.
• Vier Architekturkomponenten erfüllen beide Regulierungen gleichzeitig: unveränderlicher Audit Trail, rollenbasierte Zugriffskontrolle mit individuellen Konten, API für menschliche Aufsicht und Modellversionierung mit Deployment-Gates.
• Der Kernkonflikt: Die FDA verlangt Validierung vor dem Rollout (CSV/IQ/OQ/PQ), der EU AI Act laufendes Monitoring danach (Artikel 72). Der Rahmen der FDA für vorab festgelegte Änderungskontrolle überbrückt diese Lücke – und genau hier zahlt sich Computersystemvalidierung für Predictive Maintenance aus, die von Anfang an auf ML zugeschnitten ist.
• EU AI Act Artikel 14 – menschliche Aufsicht verlangt eine programmatische API, aufrufbar durch CMMS oder ERP. Ein Oberflächenelement, das sich in automatisierten Wartungsabläufen umgehen lässt, genügt nicht.

Unsere Teams für Entwicklung von Gesundheitssoftware haben diese Übung mit doppelter Jurisdiktion für Medizinproduktehersteller wie für Klinikbetreiber durchgeführt – häufig gemeinsam mit unseren Spezialisten für Machine Learning, die die Modellseite verantworten.

FAQ

Gilt FDA 21 CFR Part 11 für jede Predictive Maintenance an Medizingeräten im Gesundheitswesen?

Nein. Es gilt, wenn das PdM-System elektronische Datensätze erzeugt oder verwaltet, die eine Predicate Rule verlangt – etwa Wartungs- oder Kalibrierdatensätze nach 21 CFR Part 820. Ein PdM-Werkzeug, das ausschließlich interne Analysen erzeugt, ohne Datensätze zu produzieren, die ein Inspektor prüfen würde, fällt wahrscheinlich nicht direkt in den Part-11-Bereich. Diese Einordnung sollte aber im Einzelfall bestätigt werden.

Ist Predictive Maintenance an Medizingeräten automatisch Hochrisiko-KI nach dem EU AI Act?

Nicht automatisch, aber häufig. Ist das überwachte Gerät selbst ein Medizinprodukt unter der EU-MDR 2017/745 und wirkt das PdM-System als Sicherheitsbauteil, fällt es typischerweise unter Anhang III Punkt 5(a) als Hochrisiko-KI. Systeme, die nur betriebliche Analysen ohne Sicherheitsbezug erzeugen, können außerhalb dieser Klassifizierung liegen – auch das ist eine Einzelfallentscheidung entlang der Zweckbestimmung. Diese Einordnung ist im Kern eine Klassifizierungsübung zum AI Act für Medizinprodukte und Teil der SaMD-Compliance für Medizinprodukte-Software – sie lohnt sich vor Entwicklungsbeginn, nicht erst nach der Prüfung durch den Notified Body.

Wie passt Modell-Retraining in die Compliance mit FDA 21 CFR Part 11?

Jedes Retraining gilt als Änderung an einem validierten System. Es muss im Audit Trail protokolliert werden – mit auslösender Person, Modellversion davor und danach, Begründung und Validierungsergebnissen. Das entspricht §11.10(e) und der üblichen Praxis der Änderungskontrolle in der Computersystemvalidierung. Damit sind auch die Anforderungen von 21 CFR Part 11 an Machine Learning an dieser Stelle erfüllt.

Welche Frist setzt der EU AI Act für Predictive Maintenance an Medizingeräten?

Für Systeme, die als Hochrisiko-KI eingeordnet sind, ist die volle Konformität mit Verordnung (EU) 2024/1689 bis zum 2. August 2026 erforderlich.

Kann dieselbe Audit-Trail-Architektur die Anforderungen von FDA 21 CFR Part 11 und EU AI Act erfüllen?

Weitgehend ja. Ein unveränderlicher, personenbezogen zugeordneter Audit Trail mit Zeitstempel erfüllt auf FDA-Seite §11.10(e) und speist auf EU-Seite direkt die Berichterstattung zum Post-Market-Monitoring nach Artikel 72. Das Signaturformat und einige jurisdiktionsspezifische Einreichungen müssen weiterhin separat gebaut werden, aber der Audit Trail selbst ist eine gemeinsam genutzte Komponente. Genau darin liegt der Hebel für Compliance bei Predictive Maintenance für Medizingeräte.

Sprechen Sie unser Team an und erhalten Sie 25 % Rabatt auf Ihr erstes Projekt mit Elinext.