Wenn Sie eine Software entwickeln, die sich als Medizinprodukt nach Medical Device Regulation (MDR) qualifiziert, ist Validierung eines der kritischsten Themen. Eine erfolgreiche Validierung Ihrer Software ist absolute Voraussetzung, um Ihr Medizinprodukt auf den Markt zu bringen.
Doch was genau ist mit der Validierung von Software gemeint? Welche Software muss überhaupt validiert werden? Und wie sieht diese Validierung in der Praxis aus? Unser Leitfaden gibt Ihnen konkrete Antworten auf alle Aspekte dieser Fragen.
Arten der Validierung in Bezug auf Software-Medizinprodukte
Wenn in Bezug auf Software-Medizinprodukte von “Validieren” die Rede ist, kann sich dies auf völlig unterschiedliche Dinge beziehen. Wir müssen daher erstmal grundlegend verstehen, in welchem Kontext dieser Begriff verwendet wird.
Es gibt im Allgemeinen folgende Kategorien, in denen der Begriff “Software-Validierung” verwendet wird:
- #1 Validierung der eingesetzten Computersoftware: Computer Systems Validation (CSV)
- #2 Validierung des Software-Medizinprodukts selbst
- #2a Validierung der Zweckbestimmung Ihres Software-Medizinprodukts: klinische Bewertung
- #2b Validierung der Anforderungen aller Stakeholder an das Software-Medizinprodukt: User Needs bzw. Stakeholder Requirement Validierung
- #2c Validierung der Gebrauchstauglichkeit Ihres Software-Medizinprodukts nach IEC 62366
Zumeist werden mit “Software-Validierung” entweder Kategorie #1 oder Kategorie #2a gemeint. Das kommt aber natürlich auf den Kontext an. Daher ist ein holistisches Verständnis dieser Aspekte wichtig. Wir gehen im Folgenden auf alle Kategorien ein und erläutern diese im Detail.
#1 Validierung der eingesetzten Computersoftware: Computer Systems Validation (CSV)
Im Kontext der Medizinprodukt-Software-Validierung wird auch häufig von der Validierung der eingesetzten Computer-Software geredet. Ein Hersteller eines MDR-Medizinprodukts muss Computer-Software validieren, die innerhalb des Qualitätsmanagements genutzt wird.
Dies wird in der ISO 13485 4.1.6 weiter spezifiziert: “Die Organisation muss Verfahren für die Validierung der Anwendung der Computersoftware im Qualitätsmanagementsystem dokumentieren.”
Eingesetze Computer-Software bezieht sich hierbei nicht auf Ihr eigentliches Software-Medizinprodukt. Gesprochen wird hierbei von jeglichen eingesetzten Software-Tools, die einen Einfluss auf Ihr Qualitätsmanagementsystem oder die Sicherheit oder Leistungsfähigkeit Ihres Medizinprodukts haben.
Wir sprechen daher gerne auch von “Software-Tools”, weil es den Unterschied zu Ihrem eigentlichen Software-Medizinprodukt und den verwendeten Bibliotheken besser zum Ausdruck bringt. Wichtig: Software-Bibliotheken und Frameworks, die Sie in Ihr Software-Medizinprodukt einbauen, sind keine Software-Tools, sondern SOUP (Software of Unknown Provenance) nach IEC 62304. Diese SOUPs müssen nicht die Validierung der Software-Tools durchlaufen, sondern sind Teil eines gesonderten SOUP-Evaluations-Prozesses, den wir hier nicht näher erläutern. Erfahren Sie mehr zu SOUPs in diesem Artikel: IEC 62304: Software-Lebenszyklus-Prozesse von Medizinprodukten
Beispiele für relevante Software-Tools, die validiert werden müssen, könnten sein:
- Dokumentations-Software: Confluence, Word, Google Docs etc.
- Task-Management-Software: Jira, Todoist etc.
- Entwicklungsumgebungen (IDE) für Ihr Produkt: Xcode, Android Studio, WebStorm, Eclipse etc.
- Dokumenten-Ablage-Software: Dropbox, Google Drive, OneDrive etc.
- usw.
Die Liste Ihrer eingesetzten Tools wird entsprechend sehr lang sein, da für die effiziente Entwicklung einer modernen Software eben sehr viel Fremdsoftware eingesetzt wird.
Das Gute: Sie müssen nicht jedes dieser Software-Tools umfangreich validieren. Der Validierungs-Prozess folgt einem Risiko-basierten Ansatz. Demnach fokussieren Sie sich auf die Software-Tools, die den größten (indirekten) Einfluss auf die Qualität des Produkts und die Patientensicherheit haben. Eine Fehlfunktion in einem Versions-Verwaltungs-System ist demnach verhältnismäßig schwerwiegend, weil ein Anwender so ggf. eine falsche Software-Version ausgeliefert bekommt. Eine Fehlfunktion in einem Bewerbermanagement-System hat hingegen meist kaum Einfluss auf die Produktqualität.
In einem zukünftigen Artikel werden wir genauer beschreiben, wie diese Tools-Validierung abläuft. Melden Sie sich gern hier zum Newsletter an, wenn Sie hierzu benachrichtigt werden möchten:
#2 Validierung des Software-Medizinprodukts selbst
#2a Validierung der Zweckbestimmung Ihres Software-Medizinprodukts: klinische Bewertung
Um Ihr Software-Medizinprodukt (SaMD) in der EU auf den Markt zu bringen, müssen Sie validieren, dass dieses seine medizinische Zweckbestimmung erfüllt. Um dies zu tun, ist unter anderem eine sogenannte klinische Bewertung Ihres Medizinprodukts notwendig. Diese klinische Bewertung verfolgt das Ziel, den klinischen Nutzen Ihres Produkts nachzuweisen, welcher in seiner Zweckbestimmung definiert ist – das versteht man dann unter “Validierung der Zweckbestimmung“. Zur klinischen Bewertung kann zum Beispiel eine Literaturrecherche und die Durchführung eigener Studien zählen.
Doch bevor Sie die Zweckbestimmung Ihres Medizinprodukts validieren können, müssen gewisse Voraussetzungen erfüllt sein, wie im nächsten Kapitel beschrieben wird.
Basis-Arbeiten zur Validierung der Zweckbestimmung
Hierfür müssen Sie im ersten Schritt vor allem erstmal die Zweckbestimmung für Ihr Produkt definieren. Dies ist natürlich die Basis für deren Validierung. Wie genau Sie Ihre Zweckbestimmung Ihres Medizinprodukts finden und definieren, können Sie in unserem umfangreichen Leitfaden nachlesen: Formulierung der Zweckbestimmung für (Software-)Medizinprodukte. Sie sollten selbstverständlich auch überprüfen, ob Ihre Software mit der angegeben Zweckbestimmung überhaupt ein Medizinprodukt nach MDR ist (siehe auch unseren Leitfaden: Ist Ihre App ein Medizinprodukt?). Wenn dies der Fall ist, müssen Sie im nächsten Schritt die Risikoklasse Ihres SaMD bestimmen (siehe auch unseren Leitfaden zur Risiko-Klassifizierung nach MDR), weil diese einen starken Einfluss auf die Gestaltung der Validierung hat.
Klinische Bewertung
Nachdem Sie Ihre Software fertig entwickelt haben, ist es Zeit für die klinische Bewertung bzw. Validierung Ihres Produkts. In diesem Rahmen weisen Sie nach, dass Ihr Produkt sowohl die Zweckbestimmung erfüllt als auch sicher in der Anwendung ist bzw. keine inakzeptablen Gesundheitsrisiken mit sich führt.
Angenommen, Sie haben ein Produkt, das als Zweckbestimmung die Therapie von schweren Depressionen angibt. Hierfür müssten Sie nachweisen, dass die Anwendung/Nutzung Ihrer Software z.B. zur Linderung von Depressions-Symptomen führt. Gleichzeitig müssen Sie nachweisen, dass keine inakzeptablen Gesundheitsrisiken durch die Anwendung entstehen (z.B. der Suizid des Anwenders durch eine falsche Behandlung). Weiterführende Informationen finden Sie in unserem umfangreichen MDR-Guide: Klinische Bewertung von Software-Medizinprodukten
#2b Validierung der Anforderungen aller Stakeholder an das Software-Medizinprodukt: User Needs bzw. Stakeholder Requirement Validierung
Neben der klinischen Bewertung Ihres Produkts müssen Sie nach IEC 82304 die Anforderungen der relevanten Stakeholder identifizieren und validieren. Stakeholder sind bei einer Patienten-zentrierten Anwendung z.B.:
- Patienten als Hauptnutzer der App
- Ärzte, welche über einen Videochat in der App mit dem Patienten kommunzieren
- Content-Administratoren, die Texte, Bilder und Video einpflegen
- Super-Administratoren, die User Management betreiben
- Gesetzliche Vertreter (z.B. BfArM, die Aufsichtsbehörde oder benannte Stelle)
Die Begriffe Stakeholder-Requirements, User Needs und Nutzer-Anforderungen werden zumeist synonym verwendet. Beispiele für Stakeholder-Requirements teilen sich z.B. in folgende Kategorien:
- Funktionale Anforderungen (“Als Nutzer möchte ich Übungen in der App zur Verbesserung meiner Lebensqualität durchführen.”)
- Nicht-Funktionale Anforderungen
- Erfüllung des medizinischen Zwecks der Anwendung
- Patientensicherheit (Gesundheit)
- Cyber-Security-Anforderungen bzw. Anforderungen an die Datensicherheit
- Gesetzliche Anforderungen, wie Labelling (CE-Mark in der App mit Hersteller-Informationen) für MDR-Produkte oder die DSGVO für Datenschutz-Themen
- Nutzerfreundlichkeit der Anwendung
- usw.
Nachdem alle Anforderungen strukturiert identifiziert und beschrieben wurden, müssen diese spätestens nach Fertigstellung der Entwicklung validiert werden. Es muss ein Validierungsplan erstellt werden und nach Abschluss der Validierung ein Validierungs-Bericht. Dies kann für jeden User Need anders aussehen. Einige Beispiele für die Validierung der Stakeholder-Requirements könnten sein:
| Stakeholder-Requirement | Validierungs-Plan | Validierungs-Bericht |
| “Als Nutzer möchte ich Übungen in der App zur Verbesserung meiner Lebensqualität durchführen.” |
|
|
| “Als Nutzer möchte ich, dass meine Daten sicher gespeichert und verarbeitet werden und somit vor unauthorisiertem Zugriff und Manipulation geschützt sind” |
|
|
#2c Validierung der Gebrauchstauglichkeit Ihres Software-Medizinprodukts nach IEC 62366
Für die erfolgreiche Zulassung Ihres Software-Medizinprodukts müssen Sie die Gebrauchstauglichkeit Ihrer Software validieren. Die Norm IEC 62366 definiert konkrete Anforderungen an diese Validierung.
Die Gestaltung der Benutzeroberfläche einer Anwendung sollte demnach nicht nur ansprechend sein, sondern auch dazu beitragen, Fehler bei der Verwendung zu vermeiden. Ein Beispiel wäre eine App zur Steuerung einer Insulinpumpe: Es muss dem Patienten deutlich kommuniziert werden, welcher Knopf eine Insulininjektion auslöst, da eine Überdosis im schlimmsten Fall sogar tödlich sein kann.
Die IEC 62366, eine Norm für die Gebrauchstauglichkeit von Medizinprodukten, beschäftigt sich genau mit diesem Thema. Oft sind Todesfälle bei Medizinprodukten nicht auf technische Fehlfunktionen zurückzuführen, sondern auf mangelhafte Gebrauchstauglichkeit und falsche Anwendung. Das Usability Engineering, also die Gewährleistung der Gebrauchstauglichkeit, ist auch Teil des Risikomanagements. Um sicherzustellen, dass ein Produkt gebrauchstauglich ist, müssen Sie gegebenenfalls im Rahmen der sogenannten summativen Evaluation eine Usability-Studie durchführen.
Verifizierung vs. Validierung
Die Unterscheidung zwischen Verifizierung und Validierung ist für viele Hersteller eine Quelle der Verwirrung. Um den Unterschied besser zu verstehen, gibt es eine einfache Faustregel:
- Verifizierung: “Wurde das Produkt richtig umgesetzt?”
- Validierung: “Wurde das richtige Produkt umgesetzt?” oder “Erfüllt das Produkt seinen Zweck und die daran gestellten Anforderungen?”
Die Verifizierung von Software-Medizinprodukt kann zum Beispiel durch Software-System-Tests erfolgen, bei denen man das Ergebnis mit den klaren Produktspezifikationen vergleicht. Beispielsweise könnte man überprüfen, ob eine App Therapieempfehlungen auch so anzeigt, wie es in den Anforderungen beschrieben ist.
Die Validierung hingegen konzentriert sich auf die Wirksamkeit des Produkts und kann bei Medizinprodukten zum Beispiel durch klinische Studien erfolgen. Beispielsweise könnte man überprüfen, ob die von einer App empfohlenen Therapien tatsächlich die Erkrankung lindern.
Fazit zur Validierung von Medizinprodukt-Software
Wenn von Validierung im Kontext von Software als Medizinprodukt gesprochen wird, wird nicht immer das Gleiche gemeint. Die Validierung kommt in verschiedenen Anwendungsbereichen bei der Entwicklung Ihres medizinischen Produkts zum Einsatz.
Besonders wichtig zum Verständnis ist die Unterscheidung zwischen der Validierung von eingesetzter Software und der Validierung des Software-Medizinprodukts selbst.
Bei ersterer kann man als Faustregel sagen, je kritischer eine Software für Ihr Qualitätsmanagementsystem ist, desto strenger muss ihre Validierung ausfallen.
Bei der Validierung des Software-Medizinprodukts selbst spielen die Zweckbestimmung und die Stakeholder Requirements eine zentrale Rolle.
Die obige Übersicht hilft Ihnen hoffentlich besser zu verstehen, welche Aspekte für das Validieren von Software relevant sind und wie diese ablaufen.
Falls Sie eine Medizinprodukt-Software planen, treten Sie gern mit uns in Kontakt (Zum Formular). Wir sind auf die Entwicklung derartiger Produkt spezialisiert und setzen Ihre Software regulatorisch konform um.
