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:

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.”
  • Verifizierung der Funktionalität dieses Features (Testing, dass es Übungen gibt und diese grundsätzlich funktionieren)
  • Durchführung einer klinischen Bewertung zum Nachweis, dass die Übungen in der App zu einer Steigerung der Lebensqualität führen
  • Alle Funktionalitäten wurden umgesetzt und konnten im Zuge von System Tests verifiziert werden.
  • Die im Zuge der klinischen Bewertung durchgeführte klinische Prüfung konnte einen signifikanten Anstieg der Lebensqualität nach Nutzung der App nachweisen. Ergebnisse aus der Literatur bestätigen diese Beobachtung.
“Als Nutzer möchte ich, dass meine Daten sicher gespeichert und verarbeitet werden und somit vor unauthorisiertem Zugriff und Manipulation geschützt sind”
  • Durchführung eines Security-Pen-Test durch einen externen Sicherheitsexperten zur Überprüfung, ob die getroffenen technischen und organisatorischen Maßnahmen (z.B. nach Standard des BSI) zur Datensicherheit wirksam sind.
  • Der Security-Pen-Test fand keine kritischen Sicherheitslücken in der Software. Die gefunden Mängel wurden evaluiert und als akzeptabel bewertet.

#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.

Sie wollen eine Medical-Software-Idee realisieren?

Kontaktieren Sie uns erstmal unverbindlich. Wir schauen uns gemeinsam an, mit welchem Aufwand und in welchem Zeitrahmen eine Umsetzung möglich wäre. Außerdem können wir schon mal technisches Feedback für mögliche Vorgehensweisen zur Entwicklung der Software geben.

QuickBird Medical 

eine Abteilung von
QuickBird Studios GmbH
Nymphenburgerstr. 13-15 
80335 München

Kontakt

+49 (0) 89 54998380 [email protected]