Die Baumusterprüfung zählt zu den Konformitätsbewertungsverfahren, die die Medizinprodukterichtlinie MDD (93/42/EWG) kennt. Auch die MDR hält an der Baumusterprüfung als einem der Konformitätsbewertungsverfahren fest. Doch ist die Baumusterprüfung auch für Software geeignet?
Der Gedanke hinter der Baumusterprüfung
Die Baumusterprüfung hat den Fokus auf der Entwicklung
Medizinprodukte müssen den versprochenen Nutzen für die Patienten erfüllen, und sie müssen Risiken für Patienten, Anwender und Dritte auf ein akzeptables Maß minimieren. Das wird dann gelingen, wenn
- die Produkte während der Entwicklung in geeigneter Weise spezifiziert wurden und
- die Produkte gemäß diesen Spezifikationen produziert werden.
Das dies tatsächlich gelungen ist, müssen Hersteller im Rahmen der Konformitätsbewertungsverfahren nachweisen.
Die Baumusterprüfung als eines der Konformitätsbewertungsverfahren hat den Fokus auf der Entwicklung (dem ersten Punkt in obiger Aufzählung).
Hersteller entwickeln dann „gute“ Produkte, wenn sie entweder Fehler bei der Entwicklung – sprich in der Spezifikation der Produkte – vermeiden, und wenn sie Fehler bei der Entwicklung finden und beseitigen.
Fehler finden versus Fehler vermeiden
Die Baumusterprüfung verfolgt den Ansatz des Fehlerfindens. Man untersucht das Baumuster, ob es sicher ist und den versprochenen Nutzen liefert. Daher benötigen Hersteller bei der Baumusterprüfung kein Qualitätssicherungssystem / Qualitätsmanagementsystem für die Entwicklung. Ein vollständiges Qualitätsmanagementsystem würde Entwicklungsprozesse bedingen, die auch das Ziel der Fehlervermeidung verfolgen.
Die MDR spricht zwar auch von Lebenszyklusprozessen, die zu betrachten seien. Aber in der Festlegung dessen, was geprüft wird, kommt dieser Aspekt sehr kurz.
Was bei der Baumusterprüfung zu tun ist
Forderungen der MDR
Zuerst müssen die Hersteller bei der benannten Stelle die Baumusterprüfung beantragen und dazu die technische Dokumentation einreichen.
Dann beginnt die Arbeit der benannten Stelle. Sie ist verpflichtet, Folgendes zu prüfen:
- Lässt die technische Dokumentation den Schluss zu, dass das Produkt die Forderungen der MDR, ggf. der harmonisierten Normen und der „Common Specifications“ erfüllt?
- Sind diese Normen und „Common Specifications“ genannt und adäquat gewählt?
- Wurde das Produkt (das Baumuster) gemäß den Spezifikation (Vorgaben der Entwicklung) gefertigt?
- Liefert das Produkt den versprochenen Nutzen? Ist das in der klinischen Bewertung ausreichend belegt?
- Funktioniert das Produkt auch im Zusammenspiel mit anderen Produkten (Interoperabilität)? Das ist natürlich nur dann gefordert, wenn das Produkt für ein solches Zusammenspiel vorgesehen ist.
Die benannte Stelle kann bei Bedarf weitere Tests anfordern oder/und muss eigene Tests durchführen.
Die benannte Stelle muss anschließend einen Bericht verfassen und im Erfolgsfall ein Zertifikat erstellen.
Die MDR betont die Kompetenz und das Wissen über die Technologie bzw. Produktklasse, über die die Prüfer der benannten Stelle verfügen müssen.
Baumusterprüfung bei Software
Die benannten Stellen sind nicht dafür
Darf auch für Software eine Baumusterprüfung durchgeführt werden? Zunächst gibt es keine Einschränkung. Allerdings haben die benannten Stellen Zweifel ob der Sinnhaftigkeit. Das lässt sich erkennen, wenn man die NB-MED/2.2/Rec4 liest.
Dort stellt man fest, dass Software-Lebenszyklusprozesse notwendig seien, wie sie auch von der MDD für Software gefordert sind (und von der IEC 62304 näher beschrieben), weil bloßes Testen nicht mehr ausreichend sei, um Fehler mit hinreichender Wahrscheinlichkeit zu finden.
Das bedeutet wiederum, dass eine Baumusterprüfung unzureichend sein kann, bei der es ja v.a. um die Beurteilung des Baumusters und weniger um dessen Entstehungs- bzw. Entwicklungsgeschichte geht. Genauso könnte der letzte Satz in obiger Abbildung zu verstehen sein.
Und dennoch ist die Baumusterprüfung nicht formal verboten, in Einzelfällen kommt sie sogar bei Software zum Einsatz. Weshalb also nicht immer diesen Weg beschreiten?
Schwieriger Umgang mit Änderungen
Zum einen spricht dagegen, dass Software-Lebenszyklusprozesse als eine der grundlegenden Anforderungen gesetzlich vorgeschrieben sind. Zum anderen verliert man die Flexibilität bei der Software-Wartung. Denn jede Änderung, zumindest jede nicht triviale, würde eine erneute Baumusterprüfung notwendig machen. Und dann hat man nichts mehr gespart.
Forderung der IEC 62304 nach einem QM-System
Die Medizinprodukterichtlinie fordert – wie oben geschrieben – Lebenszyklusprozesse. Die meisten Hersteller nutzen die IEC 62304, um die Konformität mit dieser grundlegenden Anforderung nachzuweisen. Da aber die IEC 62304 selbst ein QM-System verlangt und da ein QM-System die (Software-)Entwicklung mit umfassen muss, stellt sich die Frage, weshalb man sich nicht gleich nach ISO 13485 zertifizieren lässt.
Und wenn man bereits sein ISO 13485 Zertifikat hat: Welchen Grund gibt es dann, sein Produkt ständig einer Baumusterprüfung zu unterziehen, wenn man mit einer Konformitätserklärung nach Anhang II (MDD) bzw. Anhang IX (MDR) wahrscheinlich schneller und billiger fahren würde?
Gegen eine externe Prüfung spricht nichts, aber gegen den Gedanken, nur ein fertiges Produkt zu betrachten, vieles.
