Software und KI in Medizinprodukten Was Embedded-Entwickler bei Medizinprodukten zuerst klären müssen

Zweckbestimmung, Risikoklasse, Change-Control-Prozesse: Wer Embedded-Software oder KI-Funktionen für Medizinprodukte entwickelt, trifft oft früher regulatorisch relevante Entscheidungen, als ihm bewusst ist. Ein Experte des TÜV SÜD erklärt, warum das nicht nur ein Thema für die spätere CE-Zertifizierung ist und wo genau Technik und Regulatorik zusammenhängen.

Bei der Entwicklung von Embedded-Software, Sensorik oder KI-Funktionen für ein Medizinprodukt müssen technische Entscheidungen häufig getroffen werden, bevor die regulatorischen Rahmenbedingungen geklärt sind. Das kann teuer werden. Eine falsch eingeschätzte Zweckbestimmung oder Risikoklasse zieht andere Anforderungen an Risikomanagement, Verifikation, Validierung und Cybersicherheit nach sich. Das wird mitunter erst deutlich, wenn die Zertifizierung durch eine Benannte Stelle bereits ansteht.

Eine Benannte Stellen sind unabhängige, staatlich akkreditierte Organisationen, die im Rahmen der EU-Medizinprodukteverordnung (MDR) die Konformität von Medizinprodukten prüfen und zertifizieren. TÜV SÜD ist eine davon. In einer aktuellen Pressemitteilung wirbt das Unternehmen für ein Whitepaper, das MedTech-Start-ups zu einem früheren Dialog mit Benannten Stellen rät. Das ist aus Sicht von TÜV SÜD ein Weg, um Geschäftsrisiken durch regulatorische Fehleinschätzungen zu senken. Wie tief reicht der Einfluss regulatorischer Vorgaben tatsächlich in die technische Architektur hinein und wo hört er schließlich auf? Dazu ein Gespräch mit Malte Knowles Schmidt, Global Portfolio Manager Medical Device Software, AI and Cybersecurity bei TÜV SÜD.

ELEKTRONIKPRAXIS: Welche regulatorischen Annahmen sollten MedTech-Start-ups bereits in der Konzept- und Systemarchitektur überprüfen, bevor sie wesentliche Entwicklungsentscheidungen treffen?

Knowles Schmidt: Grundsätzlich sollten alle regulatorischen Annahmen überprüft werden, bevor wesentliche Entwicklungsentscheidungen getroffen werden – insbesondere die Zweckbestimmung, die geplante Klassifizierung und die daraus resultierenden regulatorischen Anforderungen.

Eine gute Möglichkeit dafür sind Gespräche mit Benannten Stellen, bei denen Start-ups ihre Annahmen präsentieren können, unabhängig davon, ob sie noch in der Konzeptphase arbeiten oder bereits konkretere Arbeitsergebnisse vorliegen haben. Wichtig ist, dass die Hersteller ihre Annahmen durchdacht haben und deren Begründung erläutern können. Das ist die Grundlage für einen sinnvollen fachlichen Austausch mit einer Benannten Stelle.

Wie stark beeinflussen Zweckbestimmung und Risikoklasse die technische Auslegung eines Medizinprodukts, beispielsweise bei Sensorik, Embedded-Software, Cloud-Anbindung oder KI-Funktionen?

Es gibt grundsätzlich keine direkte Verbindung zwischen der technischen Auslegung eines Medizinprodukts und seiner Risikoklasse. Relevant für die Risikoklasse ist die Zweckbestimmung – der Intended Purpose des Produkts, also das, was das Produkt tun soll.

Gleichzeitig beeinflussen Zweckbestimmung und Klassifizierung die regulatorischen Anforderungen an die Entwicklung, etwa an Risikomanagement, Software, Verifikation und Validierung oder Cybersecurity. Hinzu kommen sogenannte Commercial Claims, die Fähigkeiten und Anwendung des Produkts beschreiben, sowie bestimmte Produktmerkmale.

Wenn eine bestimmte Technik oder ein bestimmtes Produktfeature bereits eine klare Zweckbestimmung vorgibt, ist das natürlich relevant für die technische Auslegung. Die technische Lösung selbst bestimmt die Risikoklasse aber nicht isoliert; Zweckbestimmung, Produktmerkmale und vorgesehene Anwendung müssen gemeinsam betrachtet werden.

Wann wird eine Änderung an Medical Device Software, einem Algorithmus oder einer Zweckbestimmung nach der Markteinführung regulatorisch relevant? Welche Prozesse sollten Hersteller dafür bereits bei der Entwicklung vorsehen?

Das hängt vom Zertifikat ab, das für das jeweilige Produkt ausgestellt wurde. Bei Klasse-IIa- und IIb-Produkten gilt: Viele Änderungen können als nicht-signifikant eingestuft werden und erfordern dann in der Regel keine aktive Interaktion mit der Benannten Stelle. Es gibt jedoch Ausnahmen, etwa wenn sich bei einem Klasse-IIb-Produkt der Intended Purpose ändert – solche Änderungen müssen der Benannten Stelle gemeldet werden. Ändert sich das Qualitätsmanagementsystem selbst, muss die Benannte Stelle aktiv eingebunden werden. Bei Klasse-III-Produkten sind Produktänderungen je nach Art und Umfang in der Regel der Benannten Stelle zu melden und gegebenenfalls freizugeben.

Diese Prozesse sollten Hersteller bereits vorab durchdenken. Das schließt die Frage ein, mit welcher Benannten Stelle wie zusammengearbeitet werden kann, um agil vorgehen zu können. Dazu gehört ein klarer Change-Control-Prozess, mit dem Änderungen bewertet und gegebenenfalls Risikomanagement und technische Dokumentation angepasst werden. Ausdrücklich gilt aber: Änderungen sind bei allen Klassen immer vom konkreten Einzelfall abhängig, die genannten Aussagen sind nicht pauschal zu verstehen.

Wie lassen sich agile Softwareentwicklung, schnelle Produktiterationen und Over-the-Air-Updates mit Risikomanagement, Verifikation, Validierung und technischer Dokumentation vereinbaren?

Das lässt sich grundsätzlich vereinbaren. Die eigentliche Frage ist, wie agil Verifikation, Validierung und technische Dokumentation beim Hersteller selbst ausgelegt sind. Diese Elemente lassen sich durchaus in den Sprintzyklus einbauen, müssen aber vollständig abgeschlossen sein, bevor ein Release erfolgen kann.

Regulatorische Anforderungen sollten deshalb von Beginn an Bestandteil des Entwicklungsprozesses sein und mit den jeweiligen Software-Releases beziehungsweise Änderungen verknüpft werden. Bei Over-the-Air-Updates kommt ein entsprechender Change-Control-Prozess hinzu, mit dem vor dem Release die regulatorischen Auswirkungen einer Änderung bewertet werden.

Es handelt sich also um nichts, was sich grundsätzlich ausschließt, sondern um eine Frage der internen Prozesse bei den Herstellern – weniger um eine Fragestellung, die die Benannten Stellen selbst betrifft.

Welche konkreten Nachweise zeigen Investoren und Entwicklungspartnern, dass ein Start-up regulatorisch belastbar aufgestellt ist, und wo liegen die Grenzen eines frühen Dialogs mit einer Benannten Stelle?

Grundsätzlich zeigt bereits jeder Dialog mit einer Benannten Stelle, dass sich ein Start-up mit regulatorischen Fragestellungen auseinandersetzt und versucht, seine Annahmen zu verifizieren, bevor es weitergeht. Für sich genommen ist ein solcher Dialog allerdings noch kein Nachweis für regulatorische Reife. Entscheidend ist, wie die Erkenntnisse in die Entwicklungs- und Qualitätsprozesse einfließen.

Konkretere Nachweise sind beispielsweise durchgeführte Schulungen, das Vorhandensein von Personen mit regulatorischer Expertise, frühzeitige Tests wie Cybersecurity-Tests sowie eine frühe Auseinandersetzung mit Qualitätsmanagementsystemen – bis hin zu einer tatsächlichen ISO-13485-Zertifizierung. Auch eine nachvollziehbare regulatorische Strategie sowie etablierte Risiko- und Change-Control-Prozesse liefern entsprechende Evidenz.

Die Grenze liegt bei der Beratung, die eine Benannte Stelle nicht durchführen darf. Sie kann sich zu Aussagen von Herstellern verhalten, indem sie mitteilt, ob sie derselben Ansicht ist oder nicht. Wie Hersteller zu bestimmten Ergebnissen gelangen oder wie konkrete Vorgaben umzusetzen sind, liegt außerhalb dieser Dialoge. (heh)

(ID:50972381)