Schaffen der Rahmenbedingungen für die Entwicklung medizinischer Software - Einführung in die IT Validierung

Bevor wir nun endgültig mit der konkreten Entwicklung unserer medizinischen Software loslegen, möchten wir in diesem Artikel auf einen wichtigen Aspekt im regulierten Bereich hinweisen - die Infrastruktur. Den Schwerpunkt des heutigen Beitrags möchten wir auf die Validierung der verwendeten Werkzeuge legen. Zusammengefasst wird bei Produktentwicklungen im Gesundheitsbereich Qualität maßgeblich durch die Komponenten Sicherheit und medizinische Wirksamkeit definiert. Dadurch, dass die während und nach der Softwareentwicklung verwendeten Werkzeuge einen nicht unerheblichen Einfluss auf die Produktqualität haben, ist es wenig überraschend, dass es auch hierbei spezielle Anforderungen zu erfüllen gilt. Und damit sind wir auch bereits bei einem Reizbegriff angelangt - die IT-Validierung.

Regulatorische bzw. Normative Anforderungen

Die Computervalidierung von Werkzeugen wird sowohl in den europäischen Richtlinien als auch in deren nationalen Umsetzungen oftmals nicht dezidiert erwähnt - erste etwas konkretere Hinweise finden sich aber beispielsweise in der EN 13485, der Qualitätsmanagementnorm für Medizinprodukte.

  „7.6 Bei Verwendung von Computersoftware zur Erfassung und Messung festgelegter Anforderungen muss die Eignung dieser Software 
  für die beabsichtigte Anwendung bestätigt werden. Dies muss vor dem Erstgebrauch vorgenommen und wenn notwendig auch später
  bestätigt werden.“ 
  

Falls Sie also beispielsweise Maßzahlen zur Qualitätssicherung durch Bildverarbeitung oder durch automatisiert durchgeführte Computersimulationen erheben muss diese Software demnach im Idealfall vor dem ersten Einsatz validiert werden.

  „7.5.2.1 Die Organisation muss dokumentierte Verfahren für die Validierung der Anwendung der Computersoftware (und von 
  Veränderungen an solcher Software und/oder ihrer Anwendung) festlegen, die bei Tätigkeiten in der Produktion 
  und Dienstleistungserbringung eingesetzt wird und die die Fähigkeit des Produkts, festgelegte Anforderungen 
  zu erfüllen, beeinflussen kann. Solche Softwareanwendungen müssen vor dem ersten Einsatz validiert werden.“
  

Oftmals sind Sotware-Systeme im Produktionsprozessen fixer Bestandteil und haben so direkten Einfluss auf die Produktqualität. Dies ist beispielsweise bei eingebetteten Software-Systemen in Spritzgußmaschinen oder im Stand-Alone Software Bereich bei Systemen zur kontinuierlichen Integration (z.B.: Jenkins) der Fall.

Master-Validierungsplan vs. individueller Validierungsplan

Obwohl alle angeführten Systeme unterschiedliche Herkunft und Funktionalität haben, bietet es sich an, die grundsätzliche Validierungspolitik, die durchführende Organisationseinheit (z.B.: Personal, Infrastruktur), Dokumentvorlagen und andere übergeordnete Punkte in einem Master-Validierungsplan zusammenzufassen.

Die spezifischen Validierungspläne definieren zusätzlich die konkreten Aktivitäten für das jeweilige Werkzeug, wobei sich hier eine Unterteilung in einzelne Phasen anbietet. Eine Denkweise, die wir bereits aus der EN 62304, der harmonisierten Norm für Software-Lebenszyklusprozesse medizinischer Software, kennen. Und auch ein weiterer Ansatz sollte uns bekannt vorkommen: der risikobasierte Ansatz der Validierungstätigkeiten. Bereits zu einem sehr frühen Zeitpunkt sollte eine erste Risikoanalyse erfolgen, um den Fokus auf die Funktionalitäten zu legen, welche eine hohen Einfluss auf Faktoren wir die Patientensicherheit oder die Datenintegrität haben. Dies spiegelt sich unter anderem in einer detaillierten Architektur oder aufwendigen Testtätigkeiten wider. Zusammengefasst muss also die Validierung als begleitende Tätigkeit verstanden werden – und dies beinhaltet deutlich mehr als abschließende Akzeptanztests durch die Anwender. Als weitere Informationsquelle bietet sich der GAMP 5 Standard 1) an, der auch die verschiedenen Software-Kategorien (z.B.: vollständige Eigenentwicklung oder konfigurierte Software) eingeht. Doch egal um welchen Typ von Software-Systemen es sich handelt – achten Sie darauf, dass Sie Abläufe von der Planung bis hin zur Außerbetriebnahme der Software definiert haben und die entstehenden Dokumente im Kontext einer strukturierten Dokumentenlenkung gepflegt werden.

Dokumentation

Achten Sie auch im Bereich der Validierung darauf, dass die durchgeführten Schritte nachvollziehbar dokumentiert werden. Neben dem oben genannten spezifischen Validierungsplan empfehlen wir, unter anderem folgende Fragen in einem Freigabedokument für jedes spezifische Tool zu beantworten:

  1. Wo ist der zugehörige Validierungsplan abgelegt?
  2. In welcher Umgebung wird das zu beschaffende Tool eingesetzt (Server, Betriebssystem…)?
  3. Wie ist der Lebenszyklus definiert (bei eigens entwickelter Software)?
  4. Wo wird das Tool installiert, wo werden die Installationsdateien abgelegt (Konfigurationsmanagement)?
  5. Wie oft und durch wen wird überprüft, ob Bugs für dieses Tool aufgetreten sind bzw. eine Aktualisierung veröffentlicht wurde?
  6. Welche Anforderungen muss dieses Tool erfüllen (Funktionalität, Leistungsfähigkeit, Sicherheit, Wartung/ Support…)?
  7. Welche Risiken können bei Anomalie entstehen, basierend auf der Zweckbestimmung bzw. der Anforderungsspezifikation des Tools?
  8. Wie ist nachgewiesen, dass eigene MitarbeiterInnen ausreichend geschult sind um mit dem Tool zuverlässig arbeiten zu können?
  9. Was sind die Ergebnisse der IQ/OQ/PQ?
  10. Wie lautet zusammenfassend das Fazit der Tool-Validierung?

So weit also ein kurzer Einblick in diese herausfordernde Thematik. Der nächste Blog-Artikel wird sich mit der Planungsphase medizinischer Software beschäftigen und stellt gleichzeitig den Beginn des Software-Lebenszyklus dar.

1)
Good Automated Manufacturing Practice – A Risk-Based Approach to Compliant GxP Computerized Systems

Discussion

Enter your comment. Wiki syntax is allowed:
T C᠎ U G D
 
This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information