Entdecken Sie das TÜV-zertifizierte GoogleTest mit Agentic AI für C/C++-Tests!
Details ansehen »
Whitepaper
Sie möchten sich vorab einen schnellen Überblick verschaffen? Dann beginnen Sie unten.
Die Softwareentwicklung für Medizinprodukte wird durch regulatorische Auflagen im Bereich der Codeabdeckungstests zunehmend komplexer. Die FDA-Richtlinie 510(k) schreibt Kennzahlen zur Codeabdeckung für Medizinprodukte der Klassen II und III vor, wobei die Anforderungen je nach Klassifizierung variieren.
Automatisierte Testlösungen wie Parasoft C / C ++ test und Parasoft DTP Codeabdeckung automatisch messen Sie lassen sich nahtlos in moderne SDLC-Prozesse integrieren, wodurch Risiken reduziert und das Vertrauen in die Gerätesicherheit gestärkt werden. Diese Tools unterstützen Teams bei der Einhaltung der FDA-Empfehlungen und vereinfachen die Erstellung regulatorischer Dokumentationen, wobei Europa im Zuge der Globalisierung der Medizinprodukteentwicklung zunehmend auf die Standards der US-amerikanischen FDA setzt.
Die meisten von uns haben schon medizinische Geräte genutzt – von einfachen Blutdruckmessgeräten bis hin zu preiswerten Pulsoximetern aus der Apotheke, von CT-Scannern bis zu MRT-Geräten. Sie alle unterliegen in den USA der Regulierung durch die FDA.
Die Klassifizierung von Medizinprodukten hängt von der beabsichtigten Verwendung und den Anwendungsgebieten ab. Darüber hinaus erfolgt die Klassifizierung risikobasiert, d. h. das Risiko, das das Produkt für den Patienten bzw. Anwender darstellt, ist ein wesentlicher Faktor für die Zuordnung. Klasse I umfasst Produkte mit dem geringsten Risiko, Klasse III solche mit dem höchsten Risiko. Wie bereits erwähnt, unterliegen alle Produktklassen den Allgemeinen Kontrollen. Diese Allgemeinen Kontrollen sind die grundlegenden Anforderungen des US-amerikanischen Lebensmittel-, Arzneimittel- und Kosmetikgesetzes (FD&C Act) und gelten für alle Medizinprodukte der Klassen I, II und III.
Die meisten Medizinprodukte benötigen eine FDA-510(k)-Vorabbenachrichtigung oder, falls befreit, eine einfache Registrierung. Wird ein Produkt jedoch implantiert oder birgt es ein „potenziell unvertretbares Risiko für Krankheit oder Verletzung“, handelt es sich wahrscheinlich um ein Medizinprodukt der Klasse III, das eine Vorabzulassung (PMA) erfordert. Neue, innovative Produkte ohne vergleichbare Produkte („Referenzprodukte“) fallen automatisch in die Klasse III, können aber unter Umständen anstelle einer PMA das De-Novo-Verfahren durchlaufen. Nur 10 % der von der FDA regulierten Produkte gehören zur Klasse III, diese sind jedoch am stärksten mit einem höheren Risiko verbunden.
Die von der FDA verwendete Klassifizierung basiert im Wesentlichen auf dem Risiko. Alle elektrischen Geräte entsprechen der Norm IEC-60601 für elektrische Sicherheit, aber immer häufiger enthalten medizinische Geräte umfangreiche Software.
Der Softwarestandard, der am engsten mit dem FDA-Verfahren verbunden ist, ist IEC 62304. Es beschreibt den Softwareentwicklungszyklus für Medizinprodukte und erläutert die für eine sichere Konstruktion und Wartung notwendigen Aktivitäten und Aufgaben. Die Software kann ein eingebetteter oder integraler Bestandteil des Geräts sein oder selbst ein Medizinprodukt darstellen.
IEC 62304 spezifiziert Anforderungen an Software als Teilmenge der Anforderungen an ein programmierbares elektrisches medizinisches System (PEMS). Software ist eindeutig ein Bestandteil des Verifizierungsprozesses der FDA, von der Spezifizierung der Softwareanforderungen bis hin zur Integration von Softwarekomponenten in ein Softwaresystem.
Niemand wäre erfreut, wenn medizinische Geräte oder Ausrüstungen Schmerzen, Leiden oder lebensbedrohliche Zustände verursachen würden. Manchmal geschieht dies trotz aller Bemühungen von Designern, Ingenieuren, Programmierern, Produktmanagern, Compliance-Beauftragten und allen anderen an komplexen Konstruktionen Beteiligten.
Die Klassifizierungen haben sich im Laufe der Jahre geändert – Telemedizin fiel früher unter Klasse II, wurde aber in vielen Fällen in Klasse I herabgestuft. Umgekehrt wurden die Sicherheitsrichtlinien aufgrund der Bedrohung durch IoT-Botnetze verschärft.
Es gibt mindestens zwei Gründe, warum man das Risiko reduzieren möchte:
In modernen Medizingeräten werden immer mehr Funktionen durch Software bereitgestellt, von der Internetanbindung bis hin zur Datenspeicherung und -analyse. Die Entwicklung von Hardware-Anwendungsfällen muss daher auch Software-Anwendungsfälle berücksichtigen, und in vielen Fällen steigt die Anzahl der Kombinationsmöglichkeiten erheblich an.
Wie können wir sicherstellen, dass wir Testfälle für alle Bedingungen haben? Die Messung des tatsächlichen Testumfangs des Softwarecodes ist Aufgabe von Codeabdeckungstools. Manuelle FMEA-Prozesswerkzeuge reichen dafür nur begrenzt aus. Ungetestete Software ist nicht vertrauenswürdig. Dies könnte potenziell zu unsicheren und fehlerhaften Medizinprodukten führen.
Der FDA 510(k)-Prozess erfordert die Implementierung von IEC 62304, welche die folgenden Prozesse vorschreibt: Softwareentwicklung, Softwarewartung, Problemlösung, Risikomanagement und Konfigurationsmanagement.
Angesichts der stetig zunehmenden Komplexität und neuer Programmiersprachen und Technologien ist die weitestgehende Automatisierung des Entwicklungs- und Testprozesses der Schlüssel zur Qualitätsverbesserung.
Ein Schlüsselfaktor dabei ist das Testen. Die Herausforderung beim Testen besteht darin, Testfälle zu erstellen, die nicht nur übliche Abläufe, sondern auch Grenzfälle abdecken. Wie bereits erwähnt, misst die FDA der Verifizierung eine entscheidende Bedeutung bei.
Die Regeln für die FDA-Zulassung der Klasse II und der Klasse III sind schwer verständlich, da die FDA ihre Leitlinien seit Jahren nicht aktualisiert hat. Sie schreiben zwar nicht den eigentlichen Softwareentwicklungszyklus vor, aber ein Risikomanagement. Hierfür verweisen sie auf eine IEC-Norm.
Was oft fehlt, ist das Verständnis für die Rolle, die Tools zur Codeabdeckungsanalyse spielen können. Die Codeabdeckungsanalyse hilft bei der Erstellung von Testdaten, der Automatisierung von Analysen und der Automatisierung von Teilen der Berichterstattung über den Zustand des zu testenden Medizinprodukts (DUT). Sie dient außerdem dazu, sowohl der FDA als auch Ihnen selbst zu versichern, dass alle kritischen Pfade und Grenzfälle getestet wurden.
Man sollte meinen, die FDA würde klare Regeln für die erforderlichen Analysen und insbesondere die Codeabdeckung von Medizinprodukten der Klassen II und III herausgeben, doch leider tut sie dies nicht. Sie bietet lediglich die relativ alten „Allgemeinen Grundsätze der Softwarevalidierung“ an, die Prinzipien für die Validierung von Software für Medizinprodukte sowie der Software für deren Entwicklung und Herstellung beschreiben. Wer ein Medizinprodukt oder medizinisches Gerät herstellt, muss die Anforderungen und Richtlinien dieses Dokuments einhalten. Produkte der Klassen II und III benötigen zudem strenge Kontrollmechanismen für Design, Entwicklung, Test, Änderungsmanagement und Risikoanalyse.
Wird Ihre Software in einem Produkt verwendet (integriert), muss sie validiert werden. Ist die Software das gesamte Produkt selbst, müssen Sie in Ihrem 510(k)-Antrag selbstverständlich darlegen, wie sie validiert wurde. Überraschenderweise muss auch Software, die zur Entwicklung des Produkts verwendet wird, validiert werden. Daher ist es wichtig, Compiler-Toolchains und zugehörige Tools auszuwählen, die für die Entwicklung sicherheitskritischer Systeme zertifiziert sind. Die Produkte Parasoft C/C++test und C/C++test CT sind TÜV SÜD-zertifiziert.
Zu den von der FDA erläuterten bewährten Verfahren gehören:
Neben den offensichtlichen Vorteilen einer höheren Vertrauenswürdigkeit von Medizinprodukten ergeben sich weitere Nutzen. So kann beispielsweise während der Entwicklung mithilfe eines Code-Coverage-Tools überwacht werden, welche Codeabschnitte zwar eingeführt, aber noch nicht getestet wurden. Die kontinuierliche Überwachung der Codebasisänderungen verbessert die Transparenz des Produkts.
Dies stärkt nicht nur das Vertrauen der FDA in Ihr Produkt und erhöht somit die Wahrscheinlichkeit einer Marktzulassung, sondern reduziert auch den Aufwand für Entwicklung, Qualitätssicherung, Compliance und andere Bereiche. Es ist der richtige Weg – ein Schritt hin zu mehr Effizienz und Kostensenkung.
Es gibt keinen Ersatz für Einführung automatisierter Softwaretestlösungen die bereits zuvor im sicherheitskritischen Bereich eingesetzt wurden. Hier kommt Parasoft ins Spiel. Die eingebettete Software in einer Vielzahl von medizinischen Geräten, medizinischen Anlagen und anderen sicherheitsrelevanten Anwendungen wurde mit Parasoft C/C++test getestet. Vollständig integrierte Testlösung für die C/C++-Softwareentwicklung Parasoft DTP ist vom TÜV SÜD zertifiziert und wurde somit gemäß IEC 62304 für Host-basierte und eingebettete Zielanwendungen geprüft. Dadurch erfüllt es die Anforderungen nationaler, regionaler und internationaler Vorschriften zur funktionalen Sicherheit.
Durch den Einsatz einer leistungsstarken Lösung für automatisiertes Testen und analytisches Reporting müssen Softwareentwickler im Testbereich (SDETs) nicht mehr auf zeitaufwändige und fehleranfällige manuelle Verfahren angewiesen sein. Stattdessen können sie sich auf ihre Kernaufgaben in der Entwicklung konzentrieren und die Tiefe und den Umfang ihrer Tests erweitern, um qualitativ hochwertige Software zu liefern. Eine Lösung wie C/C++test, die FDA-Anforderungen erfüllt und benutzerfreundlich ist, nutzt statische und dynamische Tests, während DTP den Fortschritt in Richtung Konformität über ein zentrales Reporting- und Analyse-Dashboard verwaltet.
Automatisierung der Generierung von Unit-Testfällen C/C++test eignet sich ideal für das Testen von Medizinprodukten im Rahmen agiler Methoden wie Scrum und DevOps, da die Entwickler Unit-Tests schreiben müssen. Im Rahmen des Build-Prozesses und vor dem Einchecken des Codes führt C/C++test automatisch Unit-Tests aus, um sicherzustellen, dass der Code frei von Regressionen und anderen Fehlern ist. Zusätzlich erfasst Parasoft mithilfe konfigurierbarer Optionen die erforderlichen Codeabdeckungsmetriken.
Teams können Parasoft-Lösungen sowohl über integrierte Entwicklungsumgebungen (IDEs) als auch über die Kommandozeile oder Shell ausführen. Weitere Informationen finden Sie hier. Liste der unterstützten Toolchains hier.
C/C++test: Grün hervorgehobene Codeabdeckung und Codeabdeckungsoptionen.
Teams können in jedem Browser auf aussagekräftige Analysen zugreifen. DTP fasst die Testergebnisse in intelligenten Dashboards und detaillierten Berichten zusammen.
Parasoft DTP – vollständiges Codeabdeckungs-Dashboard.
Code-Coverage-Tools wie die von Parasoft lassen sich in eine CI/CD-Pipeline integrieren, sodass die Lösung einen Großteil der Arbeit übernimmt. Da Medizinprodukte zunehmend Ziel von Angriffen werden, ist der Druck auf Entwicklungs- und Engineering-Teams, die DevOps einführen und nun auch DevSecOps berücksichtigen sollen, enorm.
Glücklicherweise bedeutet die Fähigkeit von Parasoft, in einer beliebigen Anzahl von IDEs und/oder über die Kommandozeile ausgeführt zu werden, dass die Integration bereits gegeben ist und nur wenig bis gar keine Konfiguration erfordert.
Die Lösungen von Parasoft können Anwendungen testen, die auf folgenden Systemen laufen:
Wenn Ihr Medizinprodukt der FDA-Klasse III angehört, ist es trotz des höheren Aufwands empfehlenswert, Tests auf der Zielhardware durchzuführen, da die Standards für Klasse III deutlich höher sind. Bei Klasse II kann argumentiert werden, dass der Test auf dem Host-System akzeptabel sei.
Hier sind fünf Schritte zur Umsetzung.
Bereit, tiefer einzutauchen?
