Zweck
Dieses Dokument dient als Leitfaden für die Software Validierung und stellt die Ansichten der FDA (Food and Drug Administration) über dieses Thema dar.
Die Anleitung fasst allgemeine Validierungsprinzipien zusammen, die die FDA vorschreibt für die Validierung von Entwurfs-, Entwicklungs- und Produktionssoftware von Medizingeräten.
Rahmen
Dieser Leitfaden beschreibt, wie sich bestimmte Vorkehrungen für das Qualitätssystem von Softwrare medizinischer Geräte mit dem momemtanen Ansatz der FDA und Evaluierung von Software-Validierungssystemen treffen lassen.
Anmerkung: Das Wort ¨System¨ benutzt die FDA oft als Definition für ein Bündel mehrerer Prozesse.
Dieses Dokument zeigt Kriterien, die von der FDA für die Validierung von Software akzeptiert werden. Jedoch zeigt es nicht alle Aktivitäten und Aufgaben für die Einhaltung des Gesetzes in allen Instanzen.
Wenn Software von jemand anderem als dem Gerätehersteller entwickelt wird, kann der Software Entwickler oder Softwarehersteller (bspw. bei Standardsoftware oder zugekauften SW Komponenten) nicht direkt für die gesetzliche Konformität mit den FDA Gesetzen verantwortlich gemacht werden.
Software Validierung ist eine Anforderung der Qualitätssystemerichtlinie, welche am 7. Oktober 1996 veröffentlicht wurde (21 Code of Federal Regulation (CFR) Part 820 bzw. 61 Ferderal Register (FR) 52602). Validierungsanforderungen beziehen sich auf…
- … Software die als Komponente in medizinischen Produkten genutzt wird
- … Software die selbst ein medizinisches Produkt ist
- … Software die bei der Produktion medizinischer Produkte genutzt wird
- … Software die bei der Entwicklung medizinischer Produkte genutzt wird
- … Software die bei der Implementierung des Qualitätssystems des Medizingeräteherstellers genutzt wird
- … Software die das Device Design History File aufzeichnet
Terminologie
Requirement
Ein Requirement ist jedes Bedürfnis oder jede Erwartung an ein System oder dessen Software.
Es gibt die folgenden Arten von Requirements:
- Design Requirements
- Functional Requirements
- Implementation Requirements
- Interface Requirements
- Performance Requirements
- Physical Requirements
Software Requirements werden typischerweise von System Requirements hergeleitet und in funktionalen Begriffen erklärt. Sie werden genau ausgestaltet, definiert und während dem Fortschreiten des Entwicklungsprojektes beschrieben.
Spezifikation
Eine Spezifikation wird als ein Dokument, welches Requirments erklärt/darlegt, definiert (Siehe 21 CFR §820.3(y).).
Zu einer Spezifikation gehören zum Beispiel die folgenden Artefakte
- Zeichnungen
- Muster
- relevante Dokumente
- …
In der Spezifikation stehen auch Prüfkriterien und -mittel um ein Requirement hinsichtlich seiner Konformität zu überprüfen.
Es gibt die folgenden Arten von Spezifikationen
- System Requirements Specification
- Software Requirements Specification
- Software Design Specification
- Software Test Specification
- Software Integration Specification
Alle diese Spezifikationsdokumente definieren spezifierte Requirements und dienen als ¨Design Output¨, wofür verschiedenste Formen der Verifikation notwendig sind.
Verifizierung und Validierung
Die Prozesse des Qualitätsmanagmentsystems werden in der ISO-Norm ISO 8402:1994 beschrieben, welche die Begriffe Verifikation und Validierung als zwei unterschiedliche und eindeutige Dinge definiert. Demgegenüber gibt es viele Software Engineering Zeitschriften, Artikel und Fachbücher, welche die Begriffe ¨Validierung¨ und ¨Verifikation¨ wie Synonyme behandeln.
Die Definitionen werden hier nach der Norm gewählt.
Software Verification
Software Verifikation führt den objektiven Beweis, dass der ¨Design Output¨ einer einzelnen Phase im Softwareentwicklungslebenszyklus alle spezifizierten Requirements erfüllt.
Software Verifikation überprüft die Widerspruchsfreiheit, die Vollständigkeit und die Korrektheit von Software und ihrer Dokumentation, wie sie entwickelt wird und unterstützt anschließend Schlussfolgerungen ob die Software validiert ist.
Software Tests sind eine von mehren Verifikationsmöglichkeiten, die belegen sollen dass das Softwareentwicklungsergebnis (Design Output) den eingeflossenen Requirements (Design Input) entspricht.
Verfikationsmöglichkeiten/Aktivitäten zur Verifizierung von Software sind u.a.
- Code Analysen
- Softaretests
- Code-Durchgänge bzw. Debugging
- Logging
- Unit Tests …
- Dokumentenreviews
- und viele weitere Techniken …
Software Validierung
Software Validierung ist Teil der Design Validierung für ein fertiges Gerät, wird aber nicht separat in der Qualitätssystemverordnung aufgeführt.
Die FDA erwähnt Software Validierung als…
¨… Bestätigung durch Untersuchungen und Erbringung eines objektiven Beweises, dass die Software Spezifikation konform zu den Benutzeranforderungen und dem vorgesehenem Verwendungszeck ist und das einzelne Requirements, die durch Software implementiert wurden, durchgängig erfüllt sind.¨In der Praxis können Software Validierungsaktivitäten, die sicherstellen ob die Software Requirements erfüllt sind, sowohl während der Entwicklung als auch am Ende des Software Development Life Cycles auftreten.
Seit Software für gewöhnlich ein Teil größerer Hardwaresysteme ist, wird die Softwarevalidierung den Beweis beinhalten, dass alle Software Requirements korrekt , komplett und nachvollziehbar/rückverfolgbar zu den System Requirements implementiert/umgesetzt wurden.
Die Schlussfolgerung darauf, dass Software validiert ist, hängt stark von ausführlichen Softwaretests, Überprüfungen, Analysen und anderen Software Verifikationsaktivitäten ab, die in den verschiedensten Phasen des Software Development Life Cycles ausgeführt werden.
Das Testen der Softwarefunktionalität des Gerätes in einer simulierten Benutzungsumgebung und Benutzer-seitiges Testen sind typische Bestandteile des allgemeinen Design Validierungsprogrammes.
Software Verifikation und Validation ist schwer, weil ein Entwickler nicht ewig testen kann. Es ist auch nicht leicht zu wissen, wieviel Beweisführung notwendig ist. Software Validierung beinhaltet die Entwicklung eines gewissen Vertrauensgrades (¨level of confidence¨) in die Erfüllung der Anforderungen, Benutzererwartungen und automatisierten Softwarefunktionen und -features des Gerätes.
Maßnahmen über gefundene Defekte in Spezifikationsdokumenten und Abschätzungen über verbleibende Defekte, Testabdeckungen und andere Techniken werden alle genutzt um einen angemessenen Vertrauensgrad (¨level of confidence¨) zu entwickeln, bevor das Produkt in den Markt kommt.
Der Vertrauensgrad, der Grad der Softwarevalidierung und -verifikation, sowie der benötigte Testaufwand wird in Abhängigkeit des Sicherheitsrisikos und der Gefahr (Hazard) der automatisierten Funktionen des Gerätes variieren.
Zusätzliche Leitlinien bezüglich des Risikomanagements für Software beinhaltet der internationale Standard ISO/IEC 14971-1 und IEC 60601-1-4 (Referenziert in Anhang A).
IQ/OQ/PQ
Für viele Jahre haben sowohl die FDA, als auch die regulierte Industrie versucht Software Validierung im Kontext der Prozessvalidierungsterminologie zu verstehen und zu definieren. Zum Beispiel beschreiben Industriedokumente und andre FDA Validierungsrichtlinien manchmal die Benutzer-seitige Software Validierung in den Begriffen:
- Installationsqualifikation (IQ)
- Operationale Qualifikation (OQ)
- Performancequalifikation (PQ)
Diese Begriffe und zusätzliche Informationen bezüglich der Begriffe IQ,OQ und PQ können in den folgenden FDA Richtlinien gefunden werden:
- Guideline on General Principles of Process Validation (May 1987)
- Glossary of Computerized System ans Software Development Terminology (August 1995)
Während die IQ/OQ/PQ Terminologie ihren Zweck sehr gut erfüllt hat und eine von mehreren gültigen Möglichkeiten für die Organisation von Softwarevalidierungsaufgaben auf der Benutzerseite ist, wird sie von vielen Softwareexperten nicht ausreichend verstanden und wird hier daher nicht weiter behandelt. Jedoch müssen sowohl dem FDA Personal, als auch dem Personal des Geräteherstellers die tatsächlichen Unterschiede in der Terminologie bewusst sein, falls Informationenen über Software Validierung eingefordert werden.
Software Entwicklung als Teil des System Designs
Die Entscheidung Systemfunktionalität durch Software zu implementieren wird typischerweise während des System Designs gemacht. Software Requirements sind üblicherweise von den allgemeinen System Requirements und dessen Design, welches beabsichtigt diverse Teile in Software zu implementieren, hergeleitet.
Für ein fertiggestelltes Gerät gibt es einen Anwenderbedarf (user needs) und einen Verwendungszweck (intended use) , wobei Benutzer in der Regel die Entscheidung, welche Requirements durch Hardware oder Software realisiert werden, nicht treffen.
Folglich muss Software Validierung im Kontext der Gesamtvalidierung des Systems betrachtet werden.
Ein ausdefiniertes Lastenheft präsentiert den Anwenderbedarf und den Verwendungszweck, für den das Produkt entwickelt wird/wurde. Das Primärziel von Softwarevalidierung ist zu zeigen, dass fertige Softwareprodukte die dokumentierten Software Requirements und System Requirements erfüllen.
Die Korrektheit und Komplettheit der System Requirements und Software Requirements wird als Teil des Design Validierungsprozesses des Gerätes verstanden. Software Validierung beinhaltet die Konformitätsbestätigung aller Software Spezifikationen und die Bestätigung das alle Software Requirements zurückfolgbar (Tracability) in die Systemspezifikationen sind.
Das Nachweisen und Belegen der allgemeinen Design Validierung des Gesamtsystems ist ein wichtiger Teil um sicherzustellen, das alle Aspekte des Medizingerätes mit den Benutzderbedarfen und dessen Verwendungszweck konform sind.
Unterschiede von Software zu Hardware
Obwohl Software und Hardware oft die selben Engineeringaufgaben haben, gibt es gravierende Unterschiede.
Hier einige Beispiele:
- Die häufigsten Softwareprobleme sind auf Fehler zurückzuführen, die während des Design und Development Prozesses gemacht wurden, während die Qualität eines Hardware Produktes stark von Design, Entwicklung und der Produktion abhängt, ist die Qualität eines Software Produktes primär von Design und Entwicklung mit wenig Bedenken bzgl. Ihrer Herstellung geprägt. Softwareerstellung bedeutet lediglich das Kopieren/Vervielfältigen von Programmen, was leicht zu verifizieren ist. Es ist nicht schwer tausende Kopien eines Programmes herzustellen die exakt wie das Original funktionieren. Die Schwierigkeit besteht darin, dass das Original-Programm alle Spezifikationen erfüllt.
- Software kann eine alternative Serie von Anweisungen ausführen, die von der ursprünglichen Eingabe abhängig sind. Dies ist der am meisten beitragende Faktor für die unterschiedliche Charakteristik von Hardware und Software und ihrer Komplexität. Sogar kurze Programme können sehr komplex und schwer zu verstehen sein
- Üblicherweise kann das Testen alleine nicht sicherstellen, dass Software vollständig und korrekt ist. Zusätzlich zum Testen werden weitere Verifikationsmaßnahmen und ein gut strukturierter und dokumentierter Entwicklungsprozess kombiniert um einen umfassenden Validierungsansatz sicherzustellen.
- Im Gegensatz zu Hardware ist Software nicht physisch und kann daher nicht verschleissen. Software kann sich im Alter verbessern, wenn verborgene Defekte aufgedeckt und entfernt werden. Die Tatsache, dass Software Updates und Änderungen erhält, birgt die Gefahr dass neue Defekte entstehen können, die durch die Änderung kommen können.
- Im Gegensatz zu manchen Hardwarefehlern, treten Softwarefehler häufig ohne Vorwarnung auf. Programmverzweigung, die es erlaubt verschiedene Programmabschnitte während der Ausführung zu durchlaufen, kann Fehler noch lange Zeit nach der Markteinführung verstecken.
- Eine weitere Charakteristik von Software ist die Leichtigkeit und Geschwindigkeit in der sie geändert werden. Dieser Faktor lässt Soft- und Hardwareexperten glauben, dass Software Probleme leicht gelöst werden können. Die Kombination mit dem fehlenden Verständnis von Software lässt Manager glauben, dass kontrolliertes Engineering bei Software nicht zu wichtig ist, wie bei Hardware. In Wirklichkeit ist aber genau das Gegenteil der Fall. Wegen der Komplexität sollte der Entwicklungsprozess von Software stärker kontrolliert werden, als der von Hardware, um Probleme die später schwer erkannt werden können im Entwicklungsprozess zu verhindern.
- Im Software Code unbedeutend erscheinende Änderungen können unerwartete und sehr signifikante Probleme an einer anderen Stelle des Programmes verursachen (Seiteneffekte).
- Aufgrund der hohen Nachfrage an Softwareexperten und ihrer Mitarbeit in verschiedenen Projekten an unterschiedlichen Orten, muss das Softwarepersonal, welches Änderungen an der Originalsoftware macht, nicht in die Erstellung der Oríginalsoftware involviert sein. Eine genau Dokumentation der Software ist unerlässlich.
- Historisch gesehen sind Softwarebausteine nicht so häufig von Standardisierung und Änderungen wie HW Komponenten betroffen. Jedoch fangen die Entwickler von medizinischen Geräten an komponentenbasierte Entwicklungstools und -techniken zu nutzen. Objektorientierte Methoden und die Benutzung von Standardsoftwarebausteinen versprechen eine schnellere und weniger kostspielige Entwicklung. Jedoch benötigen komponentenbasierte Ansätze eine besondere Achtsamkeit während der Integration. Vor der Integration wird Zeit benötigt um wiederverwendbare Software vollends zu definieren und entwickeln und um das Verhalten von Standardsoftwarekomponenten gänzlich zu begreifen.
Aus diesen und den selbern Gründen, benötigt Software Engineering eine stärkere Kontrolle als Hardware Engineering.
Vorteile von Softwarevalidierung
Softwarevalidierung ist ein kritisches Werkzeug, welches benutzt wird um die Qualität von Gerätesoftware sicherzustellen.
Softwarevalidierung …
- … verbessert die Gebrauchstauglichkeit
- … die Ausfallsicherheit des Gerätes,
- … führt zu sinkenden Fehlerraten,
- … führt zu weniger Rückrufen und Korrekturarbeiten,
- … führt zu einer Verringerung des Patienten- und Benutzerrisiko
- … führt zu reduzierten Haftungsbedingungen
- … reduziert die Langzeitkosten von Software …
- … durch Verbesserung der Betriebssicherheit bei Softwareänderungen und der Revalidierung der geänderten Software
- … durch die Reduzierung von Wartungsaufwänden
Design Review
Design Reviews sind eine dokumentierte, umfassende und systematische Überprüfungen des Designs um die Angemessenheit der Design Requirements zu bewerten, deren Tauglichkeit sicherzustellen und Probleme zu identifzieren. Während in einem Entwicklungsteam während eines Softwareprojektes viele formlose technische Design Reviews stattfinden können, ist ein formelles Design Review strukturierter und enthält Beteiligung von anderen Mitarbeitern außerhalb des Entwicklungsteams. Formelle Design Reviews können Ergebnisse von anderen formellen oder informellen Design Reviews referenzieren oder einbeziehen. Design Reviews können separat für die Software durchgeführt werden, nachdem die Software mit der Hardware in ein System integriert wurde.
Design Reviews sollten die Überprüfung
- zur Einhaltung des Development Planes
- der Requirements Spezifikation
- der Design Spezifikation
- des Testplans und -prozeduren
- allen anderen Dokumenten und Akvtitäten die mit dem Projekt in Verbindung gebracht werden
- Ergebnisse von Verifikation jedes Stadiums des defnierten Lebenszyklusses
- Valildierungsergebnisse des Gesamtgerätes
enthalten.
Design Reviews sind das Primärwerkzeug für das Management und die Bewertung von Entwicklungsprojekten. Zum Beispiel erlauben es formelle Design Reviews zu bestätigen, dass alle Ziele, die im Softwarevalidierungsplan definiert wurden, auch erreicht sind. Die Verordnung für Qualitätssysteme erfordert mindestens ein formelles Design Review während der Entwurfsphase des Gerätes. Jedoch wird empfohlen, mehrere Design Reviews durchzuführen (beispielsweise am Ende jeder Aktivität im Softwarelebenszyklus, als Vorbereitung auf die nächste Aktivität). Formelle Design Reviews sind besonders gegen Ende der Anforderungsaktivitäten, vorher wurden die Hauptressources zu den spezifischen Lösungen. Probleme die an diesem Punkt gefunden werden, können einfach gelöst werden, Zeit und Geld sparen und reduzieren die Wahrscheinlichkeit für das Übersehen eines kritischen Fehlers.
Die folgenden Antworten auf ein paar Schlüsselfragen sollten während des formellen Design Reviews dokumentiert werden:
- Wurden die entsprechenden Aufgaben, erwarteten Ergebnisse, Outputs oder Produkte definiert, dokumentiert oder implementiert für alle Aktivitäten im Softwarelebenszyklusses?
- Entsprechen die Aufgaben und die erwarteten Ergebnisse, Outputs oder Produkte aller Aktivitäten im Softwarelebenszyklus allen Anforderungen anderer Aktivitäten im Softwarelebenszyklus in Sachen Korrektheit, Vollständigkeit, Konsistenz und Genauigkeit?
- Erfüllen die Aufgaben und die erwarteten Ergebnisse, Outputs oder Produkte aller Aktivitäten im Softwarelebenszyklus die Standards, die Praxis und Abmachungen der Aktivität
- Defnieren, dokumentieren oder implementieren die erwarteten Ergebnisse, Outputs oder Produkte aller Aktivitäten im Softwarelebenszyklus eine angemessene Basis um Aufgaben für die nächste Life Cycle Aktität zu initiieren?
Grundlagen der Software Validierung
Dieser Abschnitt listet die allgemeinen Grundlagen, die bei der Validation von Software berücksichtigt werden sollten.
Requirements
Eine dokumentierte Software Requirements Spezifikation stellt eine Baseline sowohl für Validierung als auch für die Verifizierung zur Verfügung. Der Softwarevalidierungsprozess kann ohne eine ausdefinierte und dokumentierte Software Requirements Specification nicht abgeschlossen werden (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g)).
Fehlervermeidung
Softwarequalitätssicherung sollte sich auf die Verhinderung von Fehlern in den Software-Entwicklungsprozess fokussieren und nicht versuchen, die Qualität in den Softwarecode „reinzutesten“, nachdem er geschrieben wurde. Das Testen von Software ist sehr beschränkt in seiner Fähigkeit alle verborgenen Fehler im Code ans Tageslicht zu führen. Zum Beispiel verhindert die Komplexität am meisten bei Software, dass sie vollständig getestet wird.
Das Testen von Software ist eine notwendige Aktivität. Jedoch ist das Testen von Software durch Software meistens nicht ausreichend um die Gewissheit zu erlangen dass die Software ihren vorgesehenen Verwendungszweck (Intended Use) erfüllt.
Damit man der Software ein gewisses Vertrauen zukommen lassen kann, sollten Softwareentwickler eine Mischung von Methoden und Techniken anwenden um Softwarefehler zu verhindern und zu erkennen das Software Fehler auftreten können. Die beste Mischung von Methoden hängt von vielen Faktoren ab, die Eintwicklungsumgebung, Anwendung, Projektgröße und das Risiko eingeschlossen.
Zeit und Aufwand
Den Status zu erhalten, das Software validiert ist benötigt Zeit und Aufwand. Die Vorbereitung der Softwarevalidierung sollte früh anfangen, z.B. während der Design und Development Planung und dem Design Input. Der Entschluss, dass die Software validiert ist, sollte aus den gesammelten Nachweisen geplanter Validierungsaktitäten stammen, die im Laufe des Software-Lebenszyklus angefallen sind.
Software Life Cycle
Die Software Validierung gehört zu einem gelebten Softwarelebenszyklus. Der Softwarelebenszyklus beinhaltet Softwareengineeringaufgaben und Dokumentation die notwendig sind, um den Softwarevalidierungsfortschritt zu unterstützen. Zusätzlich beinhaltet der Softwarelebenszyklus spezifische Verifikations- und Validierungsaktivitäten, die dem Verwendungszweck (Intended use) der Software entsprechen. Diese Leitline empfiehlt keine einzelnen Life Cycle Modelle – nur das sie ausgewählt und für ein Softwareentwicklungsprojekt genutzt werden sollten.
Validierungspläne
Der Softwarevalidierungsprozess wird durch die Benutzung eines Planes definiert und kontrolliert. Der Softwarevalidierungsplan legt fest, was während den Softwarevalidierungsaktivitäten erreicht werden soll. Softwarevalidierungspläne sind ein bedeutsames Werkzeug für Qualitätssysteme. Softwarevalidierungspläne legen den Rahmen, den Ansatz, die Mittel, die Pläne, die Validierungsaktivtäten und ihren Umfang sowie Aufgaben und Arbeitspunkte fest.
Prozeduren
Der Softwarevalidierungsprozess wird durch die Benutzung von Prozeduren ausgeführt. Diese Prozeduren legen fest, wie die Softwarevalidierungsaktivitäten durchgeführt werden sollen.Die Prozeduren sollten die speziellen Aktionen oder Schritte identifizieren, die durchgeführt werden müssen um individuelle Validierungsaktivitäten, Aufgaben und Arbeitspunkte auszuführen.
Softwarevalidierung nach Änderungen
Durch die Komplexität von Software, kann eine unscheinbare kleine Änderung maßgebliche Auswirkungen auf das Gesamtsystem haben. Wenn eine Änderung (sogar eine kleine Änderung) an der Software gemacht wird, muss der Validierungsstatus der Software neu festgelegt und dokumentiert werden.
Wenn eine Software geändert wird, muss eine Validierungsanalyse nicht nur für die Validierung der aktuellen Änderungen gemacht werden, sondern es muss auch das Ausmaß und die Auswirkungen dieser Änderung auf das Gesamtsystem betrachtet werden.
Basierend auf dieser Analyse sollte der Softwareentwickler eine entsprechende Anzahl an Softwareregressionstests durchführen um zu zeigen, das ungeänderte aber gefährdete Systemabschnitte nicht nachteilig beeinträchtigt wurden. Design Kontrollen und entsprechende Regressionstests unterstützen das Vertrauen dass die Software nach den Änderungen noch validiert ist.
Validierungsabdeckung – Validation Coverage
Die Validierungsabdeckung sollte auf der Softwarekomplexität und ihren Sicherheitsrisiken basieren – nicht auf der Firmengröße oder irgendwelchen Randbedingungen. Die Auswahl von Validierungsaktivitäten, Aufgaben und Arbeitsschritten sollte entsprechend der Komplexität des Softwaredesigns und -nutzung und den damit verbundenen Risiken für den Verwendungszweck ausgeführt werden. Bei geringem Risiko können auch nur Baselinevalidationen durchgeführt werden. Sobald sich das Risiko erhöht, sollten zusätzliche Validierungsaktivitäten hinzugefügt werden um das zusätzliche Risiko abzudecken. Die Validierungsdokumentation sollte ausreichend sein um zu zeigen, dass alle Softwarevalidierungspläne und -prozeduren erfüllt wurden.
Unabhängigkeit vom Review – Independence of Review.
Valdierungsaktivitäten sollten mit dem Qualitätssicherheitsgebot „Unabhängigkeit vom Review“ durchgeführt werden. Selbstvalidierung ist sehr schwer. Eine unabhängige Bewertung ist immer besser, besonders bei Anwendungen mit höherem Risiko. Manche Firmen handeln für Dritte/Fremdfirmen Verifikation und Validation aus, aber diese Lösung wird nicht immer machbar sein. Ein weitere Ansatz ist es Betriebsangehörigen, die nicht in ein Design involviert sind, aber ausreichendes Wissen für die Durchführung der Projektvalidation und -verifikation besitzen, zuzuweisen.
Flexibilität und Verantwortlichkeiten
Spezielle Umsetzungen der Softwarevalidierungsgrundsätze können sich von Anwendung zu Anwendung unterscheiden. Der Gerätehersteller hat die Flexibilität bei der Wahl, wie Validierungsprinzipien ausgewählt werden, aber behält die ultimative Verantwortung zu zeigen, dass die Software validiert ist.
Software wird in einem breitem Spektrum an Umgebungen und für ein reiches Angebot an Geräten mit unterschiedlichen Risiken entworfen, entwickelt, validiert und reguliert.Medizingeräteanwendungen, die von der FDA reguliert sind, enthalten Software die …
- … eine Komponente, ein Teil oder Zuberhör eines medizinischen Gerätes ist
- … selber ein Medizingerät ist oder
- … für die Produktion, den Entwurf, die Entwicklung oder andere Teile des Qualitätssystems ist.
In jeder Umgebung, können Softwarebausteine von vielen Quellen genutzt werden um die Anwendung zu erstellen (z.B. In-House Entwicklung, Standardsoftware, Vertragssoftware, Shareware…). Zusätzlich können Softwarekomponenten in vielen Formen auftauchen (z.B. Anwendungssoftware, Betriebssysteme, Compiler, Debugger, Konfigurationsmanagmenttools und viele mehr). Die Validierung von Software in diesem Umfeld kann niederschmetternd komplex sein, außerdem ist es angebracht, dass alle Softwarevalidierungsgrundsätze berücksichtigt werden, wenn der Softwarevalidierungsprozess aufgesetzt wird. Der resultierende Softwarevalidierungsprozess sollte mit den verbundenen Sicherheitsrisiken, die mit dem System, dem Gerät, dem Produkt oder Prozess in Verbindung gebracht werden, angemessen sein.
Softwarevalidierungsaktivitäten und -aufgaben können zerstreut an verschiedenen Stellen von verschiedenen Organisationen durchgeführt werden. Jedoch, unabhängig der Verteilung, vertraglichen Beziehungen, Komponentenquellen oder der Entwicklungsumgebung bekommt der Gerätehersteller und Spezifkationsersteller die absolute Verantwortlichkeit für die Sicherstellung, das Software validiert ist.
Aktivitäten und Aufgaben
Softwarevalidierung wird während einer Serie von Aktivitäten und Aufgaben, die während den unterschiedlichen Stadien des Softwarelebenszyklusses geplant und ausgeführt werden, durchgeführt. Diese Aufgaben können einmalig oder häufig durchlaufen werden. Dies ist abhängig vom Lebenszyklusmodell (Life Cycle Model) was im Rahmen von Änderungen während des Softwareprojektfortschritts benutzt wird.
Softwarelebenszyklusaktivitäten
Diese Richtlinie empfiehlt nicht die Benutzung eines speziellen Software Life Cycle Modells. Softwareentwickler sollten ein Softwarelebenszyklusmodell etablieren, was ihrem Produkt und der Organisation entspricht. Das Softwarelebenzyklusmodell, das ausgewählt wird, sollte die Software von ihrer Geburt bis zu ihrem Ausscheiden begleiten. Aktivitäten in einem typischem Softwarelebenszyklusmodell beinhaltet
- Qualitätsplaung
- Definition der System Requirements
- Eine detailierte Software Requirements Spezifikation
- Der Aufbau des Codings
- Das Testen
- Die Installation
- Die Operation und der Support
- Die Instandhaltung
- Die Stilllegung / Retirmenent
Verifikation, Testen und andere Aufgaben die Softwarevalidierung unterstützen treten während jeder dieser Aktivitäten auf. Ein Lebenszyklusmodell organisiert diese Softwareentwicklungsaktivitäten mit unterschiedlichen Möglichkeiten und stellt ein Framework für das Monitoring und zur Kontrolle des Softwareentwicklungsprojektes bereit. Verschiedene Softwarelebenszyklusmodelle (Wasserfall, Spiralmodell, Rapid Prototyping, inkrementelle Entwicklng, … etc) sind im
FDA Glossar definiert: Glossary of Computerized System and Software Development Terminology
Diese und viele weitere Lebenszyklusmodelle werden in verschiedenen Referenzlisten im Anhang A beschrieben.
Typische Aufgaben, die Validierung begünstigen
Für jede Aktivität im Softwarelebenszyklus gibt es gewisse Aufgaben, die eine Schlussfolgerung begünstigen. Jedoch werden diese speziellen Aufgaben, die durchgeführt werden müssen, ihre Reihenfolge der Ausführung und die Iteration und das Timing ihrer Ausführungen von einem spezifischen Softwarelebenszyklusmodell und den Sicherheitsrisiken der Applikation vorgeschrieben. Für Anwendungen mit geringem Risiko könnten manche Aufgaben nicht notwendig sein. Zumindest sollte der Softwareentwickler jede dieser Aufgaben berücksichtigen, erklären und dokumentieren welche Aufgaben für die spezielle Anwendung nicht sinnvoll sind. Die folgende Diskussion ist generisch und es ist nicht beabsichtigt ein einzelnes Softwarelebenszyklusmodell vorzuschreiben oder eine Reihenfolge festzulegen, in der die Tasks abgearbeitet werden.
Qualitätsplanung
Design und Entwicklungsplanung sollte in einem Plan, der notwendige Aufgaben, Prozeduren für Anomalieberichte und Lösungen, notwendige Ressourcen und Review Anforderungen vom Management, die formelle Design Reviews beinhalten, zusammengefasst werden. Ein Softwarelebenszyklusmodell und damit verbundene Aktivitäten sollten identifziert werden, genauso wie die notwendigen Aufgaben für jede Aktivität im Softwarelebenszyklus.
Im Plan sollte enthalten sein:
- Die spezifischen Aufgaben für jede Lebenszyklusaktivität
- Aufzählungen von wichtigen Qualitätsfaktoren
— Ausfallsicherheit
— Handhabbarkeit
— Usability
— …
- Methoden und Prozeduren für jede Aufgabe
- Die Akzeptanzkriterien der Aufgaben
