Dieses Dokument dient als Leitfaden f\u00fcr die Software Validierung und stellt die Ansichten der FDA (Food and Drug Administration) \u00fcber dieses Thema dar.
\nDie Anleitung fasst allgemeine Validierungsprinzipien zusammen, die die FDA vorschreibt f\u00fcr die Validierung von Entwurfs-, Entwicklungs- und Produktionssoftware von Medizinger\u00e4ten.<\/p>\n
Dieser Leitfaden beschreibt, wie sich bestimmte Vorkehrungen f\u00fcr das Qualit\u00e4tssystem von Softwrare medizinischer Ger\u00e4te mit dem momemtanen Ansatz der FDA und Evaluierung von Software-Validierungssystemen treffen lassen.<\/p>\n
Anmerkung: Das Wort \u00a8System\u00a8 benutzt die FDA oft als Definition f\u00fcr ein B\u00fcndel mehrerer Prozesse.<\/small><\/p>\n
Dieses Dokument zeigt Kriterien, die von der FDA f\u00fcr die Validierung von Software akzeptiert werden. Jedoch zeigt es nicht alle Aktivit\u00e4ten und Aufgaben f\u00fcr die Einhaltung des Gesetzes in allen Instanzen.<\/p>\n
Wenn Software von jemand anderem als dem Ger\u00e4tehersteller entwickelt wird, kann der Software Entwickler oder Softwarehersteller (bspw. bei Standardsoftware oder zugekauften SW Komponenten) nicht direkt f\u00fcr die gesetzliche Konformit\u00e4t mit den FDA Gesetzen verantwortlich gemacht werden. <\/p>\n
Software Validierung ist eine Anforderung der Qualit\u00e4tssystemerichtlinie, welche am 7. Oktober 1996 ver\u00f6ffentlicht wurde (21 Code of Federal Regulation (CFR) Part 820 bzw. 61 Ferderal Register (FR) 52602). Validierungsanforderungen beziehen sich auf…<\/p>\n
Ein Requirement ist jedes Bed\u00fcrfnis oder jede Erwartung an ein System oder dessen Software.<\/p>\n
Es gibt die folgenden Arten von Requirements:<\/p>\n
Software Requirements werden typischerweise von System Requirements hergeleitet und in funktionalen Begriffen erkl\u00e4rt. Sie werden genau ausgestaltet, definiert und w\u00e4hrend dem Fortschreiten des Entwicklungsprojektes beschrieben.<\/p>\n
Eine Spezifikation wird als ein Dokument, welches Requirments erkl\u00e4rt\/darlegt, definiert (Siehe 21 CFR \u00a7820.3(y).).<\/p>\n
Zu einer Spezifikation geh\u00f6ren zum Beispiel die folgenden Artefakte<\/p>\n
In der Spezifikation stehen auch Pr\u00fcfkriterien und -mittel um ein Requirement hinsichtlich seiner Konformit\u00e4t zu \u00fcberpr\u00fcfen.<\/p>\n
Es gibt die folgenden Arten von Spezifikationen<\/p>\n
Alle diese Spezifikationsdokumente definieren spezifierte Requirements und dienen als \u00a8Design Output\u00a8, wof\u00fcr verschiedenste Formen der Verifikation notwendig sind.<\/p>\n
Die Prozesse des Qualit\u00e4tsmanagmentsystems werden in der ISO-Norm ISO 8402:1994 beschrieben, welche die Begriffe Verifikation und Validierung als zwei unterschiedliche und eindeutige Dinge definiert. Demgegen\u00fcber gibt es viele Software Engineering Zeitschriften, Artikel und Fachb\u00fccher, welche die Begriffe \u00a8Validierung\u00a8 und \u00a8Verifikation\u00a8 wie Synonyme behandeln.<\/p>\n
Die Definitionen werden hier nach der Norm gew\u00e4hlt.<\/p>\n
Software Verifikation f\u00fchrt den objektiven Beweis, dass der \u00a8Design Output\u00a8 einer einzelnen Phase im Softwareentwicklungslebenszyklus alle spezifizierten Requirements erf\u00fcllt.
\nSoftware Verifikation \u00fcberpr\u00fcft die Widerspruchsfreiheit, die Vollst\u00e4ndigkeit und die Korrektheit von Software und ihrer Dokumentation, wie sie entwickelt wird und unterst\u00fctzt anschlie\u00dfend Schlussfolgerungen ob die Software validiert ist.<\/p>\n
Software Tests sind eine von mehren Verifikationsm\u00f6glichkeiten, die belegen sollen dass das Softwareentwicklungsergebnis (Design Output) den eingeflossenen Requirements (Design Input) entspricht.<\/p>\n
Verfikationsm\u00f6glichkeiten\/Aktivit\u00e4ten zur Verifizierung von Software sind u.a.<\/p>\n
Software Validierung ist Teil der Design Validierung f\u00fcr ein fertiges Ger\u00e4t, wird aber nicht separat in der Qualit\u00e4tssystemverordnung aufgef\u00fchrt.<\/p>\n
Die FDA erw\u00e4hnt Software Validierung als…<\/p>\n
Software Verifikation und Validation ist schwer, weil ein Entwickler nicht ewig testen kann. Es ist auch nicht leicht zu wissen, wieviel Beweisf\u00fchrung notwendig ist. Software Validierung beinhaltet die Entwicklung eines gewissen Vertrauensgrades (\u00a8level of confidence\u00a8) in die Erf\u00fcllung der Anforderungen, Benutzererwartungen und automatisierten Softwarefunktionen und -features des Ger\u00e4tes.
\nMa\u00dfnahmen \u00fcber gefundene Defekte in Spezifikationsdokumenten und Absch\u00e4tzungen \u00fcber verbleibende Defekte, Testabdeckungen und andere Techniken werden alle genutzt um einen angemessenen Vertrauensgrad (\u00a8level of confidence\u00a8) zu entwickeln, bevor das Produkt in den Markt kommt.
\nDer Vertrauensgrad, der Grad der Softwarevalidierung und -verifikation, sowie der ben\u00f6tigte Testaufwand wird in Abh\u00e4ngigkeit des Sicherheitsrisikos und der Gefahr (Hazard) der automatisierten Funktionen des Ger\u00e4tes variieren.<\/p>\n
Zus\u00e4tzliche Leitlinien bez\u00fcglich des Risikomanagements f\u00fcr Software beinhaltet der internationale Standard ISO\/IEC 14971-1 und IEC 60601-1-4 (Referenziert in Anhang A).<\/p>\n
F\u00fcr 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:<\/p>\n
Diese Begriffe und zus\u00e4tzliche Informationen bez\u00fcglich der Begriffe IQ,OQ und PQ k\u00f6nnen in den folgenden FDA Richtlinien gefunden werden:<\/p>\n
W\u00e4hrend die IQ\/OQ\/PQ Terminologie ihren Zweck sehr gut erf\u00fcllt hat und eine von mehreren g\u00fcltigen M\u00f6glichkeiten f\u00fcr 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\u00fcssen sowohl dem FDA Personal, als auch dem Personal des Ger\u00e4teherstellers die tats\u00e4chlichen Unterschiede in der Terminologie bewusst sein, falls Informationenen \u00fcber Software Validierung eingefordert werden.<\/p>\n
Die Entscheidung Systemfunktionalit\u00e4t durch Software zu implementieren wird typischerweise w\u00e4hrend des System Designs gemacht. Software Requirements sind \u00fcblicherweise von den allgemeinen System Requirements und dessen Design, welches beabsichtigt diverse Teile in Software zu implementieren, hergeleitet.
\nF\u00fcr ein fertiggestelltes Ger\u00e4t 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.
\nFolglich muss Software Validierung im Kontext der Gesamtvalidierung des Systems betrachtet werden.<\/p>\n
Ein ausdefiniertes Lastenheft pr\u00e4sentiert den Anwenderbedarf und den Verwendungszweck, f\u00fcr den das Produkt entwickelt wird\/wurde. Das Prim\u00e4rziel von Softwarevalidierung ist zu zeigen, dass fertige Softwareprodukte die dokumentierten Software Requirements und System Requirements erf\u00fcllen.<\/p>\n
Die Korrektheit und Komplettheit der System Requirements und Software Requirements wird als Teil des Design Validierungsprozesses des Ger\u00e4tes verstanden. Software Validierung beinhaltet die Konformit\u00e4tsbest\u00e4tigung aller Software Spezifikationen und die Best\u00e4tigung das alle Software Requirements zur\u00fcckfolgbar (Tracability) in die Systemspezifikationen sind.
\nDas Nachweisen und Belegen der allgemeinen Design Validierung des Gesamtsystems ist ein wichtiger Teil um sicherzustellen, das alle Aspekte des Medizinger\u00e4tes mit den Benutzderbedarfen und dessen Verwendungszweck konform sind.<\/p>\n
Obwohl Software und Hardware oft die selben Engineeringaufgaben haben, gibt es gravierende Unterschiede.
\nHier einige Beispiele:<\/p>\n
Aus diesen und den selbern Gr\u00fcnden, ben\u00f6tigt Software Engineering eine st\u00e4rkere Kontrolle als Hardware Engineering.<\/p>\n
Softwarevalidierung ist ein kritisches Werkzeug, welches benutzt wird um die Qualit\u00e4t von Ger\u00e4tesoftware sicherzustellen.
\nSoftwarevalidierung …<\/p>\n
Design Reviews sind eine dokumentierte, umfassende und systematische \u00dcberpr\u00fcfungen des Designs um die Angemessenheit der Design Requirements zu bewerten, deren Tauglichkeit sicherzustellen\u00a0 und Probleme zu identifzieren. W\u00e4hrend in einem Entwicklungsteam w\u00e4hrend eines Softwareprojektes viele formlose technische\u00a0Design Reviews stattfinden k\u00f6nnen, ist ein formelles Design Review strukturierter und enth\u00e4lt Beteiligung von anderen Mitarbeitern\u00a0au\u00dferhalb des Entwicklungsteams. Formelle Design Reviews k\u00f6nnen Ergebnisse von anderen formellen oder informellen Design Reviews\u00a0referenzieren oder einbeziehen. Design Reviews k\u00f6nnen separat f\u00fcr die Software durchgef\u00fchrt werden, nachdem die Software mit der Hardware in ein System integriert wurde.
\nDesign Reviews sollten die \u00dcberpr\u00fcfung<\/p>\n
enthalten.<\/p>\n
Design Reviews sind das Prim\u00e4rwerkzeug f\u00fcr das Management und die Bewertung von Entwicklungsprojekten. Zum Beispiel erlauben es\u00a0formelle Design Reviews zu best\u00e4tigen, dass alle Ziele, die im Softwarevalidierungsplan definiert wurden, auch erreicht sind. Die Verordnung f\u00fcr Qualit\u00e4tssysteme erfordert mindestens ein formelles Design Review w\u00e4hrend der Entwurfsphase\u00a0des Ger\u00e4tes. Jedoch wird empfohlen, mehrere Design Reviews durchzuf\u00fchren (beispielsweise am Ende jeder Aktivit\u00e4t im Softwarelebenszyklus, als Vorbereitung auf die n\u00e4chste Aktivit\u00e4t). Formelle Design Reviews sind besonders gegen Ende der Anforderungsaktivit\u00e4ten, vorher wurden die Hauptressources zu den spezifischen L\u00f6sungen. Probleme die an diesem Punkt gefunden werden, k\u00f6nnen einfach gel\u00f6st werden, Zeit und Geld sparen und\u00a0reduzieren die Wahrscheinlichkeit f\u00fcr das \u00dcbersehen eines kritischen Fehlers.
\nDie folgenden Antworten auf ein paar Schl\u00fcsselfragen sollten w\u00e4hrend des formellen Design Reviews dokumentiert werden:<\/p>\n
Dieser Abschnitt listet die allgemeinen Grundlagen, die bei der Validation von Software ber\u00fccksichtigt werden sollten.<\/p>\n
Eine dokumentierte Software Requirements Spezifikation stellt eine Baseline sowohl f\u00fcr Validierung als auch f\u00fcr die Verifizierung zur Verf\u00fcgung. Der Softwarevalidierungsprozess kann ohne eine ausdefinierte und\u00a0\u00a0dokumentierte\u00a0Software Requirements Specification nicht abgeschlossen werden (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g)).<\/p>\n
Softwarequalit\u00e4tssicherung sollte sich auf die Verhinderung von Fehlern in den Software-Entwicklungsprozess fokussieren und nicht versuchen, die Qualit\u00e4t in den Softwarecode „reinzutesten“, nachdem er geschrieben wurde. Das Testen von Software ist sehr beschr\u00e4nkt in seiner F\u00e4higkeit alle verborgenen Fehler im Code ans Tageslicht zu f\u00fchren. Zum Beispiel verhindert die Komplexit\u00e4t am meisten bei Software, dass sie vollst\u00e4ndig getestet wird. Den Status zu erhalten, das Software validiert ist ben\u00f6tigt Zeit und Aufwand. Die Vorbereitung der Softwarevalidierung sollte fr\u00fch anfangen, z.B. w\u00e4hrend der Design und Development Planung und dem Design Input. Der Entschluss, dass die Software validiert ist, sollte aus den gesammelten Nachweisen geplanter Validierungsaktit\u00e4ten stammen, die im Laufe des Software-Lebenszyklus angefallen sind.<\/p>\n Die Software Validierung geh\u00f6rt zu einem gelebten Softwarelebenszyklus. Der Softwarelebenszyklus beinhaltet Softwareengineeringaufgaben und Dokumentation die notwendig sind, um den\u00a0 Softwarevalidierungsfortschritt zu unterst\u00fctzen. Zus\u00e4tzlich beinhaltet der Softwarelebenszyklus spezifische Verifikations- und Validierungsaktivit\u00e4ten, die dem Verwendungszweck (Intended use) der Software entsprechen. Diese Leitline empfiehlt keine einzelnen Life Cycle Modelle – nur das sie ausgew\u00e4hlt und f\u00fcr ein Softwareentwicklungsprojekt genutzt werden sollten.<\/p>\n Der Softwarevalidierungsprozess wird durch die Benutzung eines Planes definiert und kontrolliert. Der Softwarevalidierungsplan legt fest, was w\u00e4hrend den Softwarevalidierungsaktivit\u00e4ten erreicht werden soll. Softwarevalidierungspl\u00e4ne sind ein bedeutsames Werkzeug f\u00fcr Qualit\u00e4tssysteme. Softwarevalidierungspl\u00e4ne legen den Rahmen, den Ansatz, die Mittel, die Pl\u00e4ne, die Validierungsaktivt\u00e4ten und ihren Umfang sowie Aufgaben und Arbeitspunkte fest.<\/p>\n Der Softwarevalidierungsprozess wird durch die Benutzung von Prozeduren ausgef\u00fchrt. Diese Prozeduren legen fest, wie die Softwarevalidierungsaktivit\u00e4ten durchgef\u00fchrt werden sollen.Die Prozeduren sollten die speziellen Aktionen oder Schritte identifizieren, die durchgef\u00fchrt werden m\u00fcssen um individuelle Validierungsaktivit\u00e4ten, Aufgaben und Arbeitspunkte auszuf\u00fchren.<\/p>\n Durch die Komplexit\u00e4t von Software, kann eine unscheinbare kleine \u00c4nderung ma\u00dfgebliche Auswirkungen auf das Gesamtsystem haben. Wenn eine \u00c4nderung (sogar eine kleine \u00c4nderung) an der Software gemacht wird, muss der Validierungsstatus der Software neu festgelegt und dokumentiert werden. Die Validierungsabdeckung sollte auf der Softwarekomplexit\u00e4t und ihren Sicherheitsrisiken basieren – nicht auf der Firmengr\u00f6\u00dfe oder irgendwelchen Randbedingungen. Die Auswahl von Validierungsaktivit\u00e4ten, Aufgaben und Arbeitsschritten sollte entsprechend der Komplexit\u00e4t des Softwaredesigns und -nutzung und den damit verbundenen Risiken f\u00fcr den Verwendungszweck ausgef\u00fchrt werden. Bei geringem Risiko k\u00f6nnen auch nur Baselinevalidationen durchgef\u00fchrt werden. Sobald sich das Risiko erh\u00f6ht, sollten zus\u00e4tzliche Validierungsaktivit\u00e4ten hinzugef\u00fcgt werden um das zus\u00e4tzliche Risiko abzudecken. Die Validierungsdokumentation sollte ausreichend sein um zu zeigen, dass alle Softwarevalidierungspl\u00e4ne und -prozeduren erf\u00fcllt wurden.<\/p>\n Valdierungsaktivit\u00e4ten sollten mit dem Qualit\u00e4tssicherheitsgebot „Unabh\u00e4ngigkeit vom Review“ durchgef\u00fchrt werden. Selbstvalidierung ist sehr schwer. Eine unabh\u00e4ngige Bewertung ist immer besser, besonders bei Anwendungen mit h\u00f6herem Risiko. Manche Firmen handeln f\u00fcr Dritte\/Fremdfirmen Verifikation und Validation aus, aber diese L\u00f6sung wird nicht immer machbar sein. Ein weitere Ansatz ist es Betriebsangeh\u00f6rigen, die nicht in ein Design involviert\u00a0 sind, aber ausreichendes Wissen f\u00fcr die Durchf\u00fchrung der Projektvalidation und -verifikation besitzen, zuzuweisen.<\/p>\n Spezielle Umsetzungen der Softwarevalidierungsgrunds\u00e4tze k\u00f6nnen sich von Anwendung zu Anwendung unterscheiden. Der Ger\u00e4tehersteller hat die Flexibilit\u00e4t bei der Wahl, wie Validierungsprinzipien\u00a0 ausgew\u00e4hlt werden, aber beh\u00e4lt die ultimative Verantwortung zu zeigen, dass die Software validiert ist. In jeder Umgebung, k\u00f6nnen Softwarebausteine von vielen Quellen genutzt werden um die Anwendung zu erstellen (z.B. In-House Entwicklung, Standardsoftware, Vertragssoftware, Shareware…). Zus\u00e4tzlich k\u00f6nnen 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\u00dferdem ist es angebracht, dass alle Softwarevalidierungsgrunds\u00e4tze ber\u00fccksichtigt werden, wenn der Softwarevalidierungsprozess aufgesetzt wird. Der resultierende Softwarevalidierungsprozess sollte mit den verbundenen Sicherheitsrisiken, die mit dem System, dem Ger\u00e4t, dem Produkt oder Prozess in Verbindung gebracht werden, angemessen sein. Softwarevalidierung wird \u00a0w\u00e4hrend einer Serie von Aktivit\u00e4ten und Aufgaben, die w\u00e4hrend den unterschiedlichen Stadien des Softwarelebenszyklusses geplant und ausgef\u00fchrt werden, durchgef\u00fchrt. Diese Aufgaben k\u00f6nnen einmalig oder h\u00e4ufig durchlaufen werden. Dies ist abh\u00e4ngig vom Lebenszyklusmodell (Life Cycle Model) was im Rahmen von \u00c4nderungen w\u00e4hrend des Softwareprojektfortschritts benutzt wird.<\/p>\n 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\u00e4hlt wird, sollte die Software von ihrer Geburt bis zu ihrem Ausscheiden begleiten. Aktivit\u00e4ten in einem typischem Softwarelebenszyklusmodell beinhaltet<\/p>\n Verifikation, Testen und\u00a0andere Aufgaben die Softwarevalidierung unterst\u00fctzen treten w\u00e4hrend jeder dieser Aktivit\u00e4ten auf. \u00a0Ein Lebenszyklusmodell organisiert diese Softwareentwicklungsaktivit\u00e4ten mit unterschiedlichen M\u00f6glichkeiten und stellt ein Framework f\u00fcr das Monitoring und zur Kontrolle des Softwareentwicklungsprojektes bereit. Verschiedene Softwarelebenszyklusmodelle (Wasserfall, Spiralmodell, Rapid Prototyping, inkrementelle Entwicklng, … etc) sind im Diese und viele weitere Lebenszyklusmodelle werden in verschiedenen Referenzlisten im Anhang A beschrieben.<\/p>\n F\u00fcr jede Aktivit\u00e4t im Softwarelebenszyklus gibt es gewisse Aufgaben, die eine Schlussfolgerung beg\u00fcnstigen. Jedoch werden diese speziellen Aufgaben, die durchgef\u00fchrt werden m\u00fcssen, ihre Reihenfolge der Ausf\u00fchrung und die Iteration und das Timing ihrer Ausf\u00fchrungen von einem spezifischen Softwarelebenszyklusmodell und den Sicherheitsrisiken der Applikation vorgeschrieben. F\u00fcr Anwendungen mit geringem Risiko k\u00f6nnten manche Aufgaben nicht notwendig sein. Zumindest sollte der Softwareentwickler jede dieser Aufgaben ber\u00fccksichtigen, erkl\u00e4ren und dokumentieren welche Aufgaben f\u00fcr die spezielle Anwendung nicht sinnvoll\u00a0sind. Die folgende Diskussion ist generisch und es ist nicht beabsichtigt ein einzelnes Softwarelebenszyklusmodell vorzuschreiben oder eine Reihenfolge festzulegen, in der die Tasks abgearbeitet werden.<\/p>\n Design und Entwicklungsplanung sollte in einem Plan, der notwendige Aufgaben, Prozeduren f\u00fcr Anomalieberichte und L\u00f6sungen, notwendige Ressourcen und Review Anforderungen vom Management, die formelle Design Reviews beinhalten, zusammengefasst werden. Ein Softwarelebenszyklusmodell und damit verbundene Aktivit\u00e4ten sollten identifziert werden, genauso wie die notwendigen Aufgaben f\u00fcr jede Aktivit\u00e4t im Softwarelebenszyklus.<\/p>\n Im Plan sollte enthalten sein:<\/p>\n <\/p>\n <\/p>\n <\/p>\n
\nDas Testen von Software ist eine notwendige Aktivit\u00e4t. 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\u00fcllt.<\/strong>
\nDamit 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\u00f6nnen. Die beste Mischung von Methoden h\u00e4ngt von vielen Faktoren ab, die Eintwicklungsumgebung, Anwendung, Projektgr\u00f6\u00dfe und das Risiko eingeschlossen.<\/p>\nZeit und Aufwand<\/h2>\n
Software Life Cycle<\/h2>\n
Validierungspl\u00e4ne<\/h2>\n
Prozeduren<\/h2>\n
Softwarevalidierung nach \u00c4nderungen<\/h2>\n
\nWenn eine Software ge\u00e4ndert wird, muss eine Validierungsanalyse nicht nur f\u00fcr die Validierung der aktuellen \u00c4nderungen gemacht werden, sondern es muss auch das Ausma\u00df und die Auswirkungen dieser \u00c4nderung auf das Gesamtsystem betrachtet werden<\/strong>.
\nBasierend auf dieser Analyse sollte der Softwareentwickler eine entsprechende Anzahl an Softwareregressionstests durchf\u00fchren um zu zeigen, das unge\u00e4nderte aber gef\u00e4hrdete Systemabschnitte nicht nachteilig beeintr\u00e4chtigt wurden. Design Kontrollen und entsprechende Regressionstests unterst\u00fctzen das Vertrauen dass die Software nach den \u00c4nderungen noch validiert ist.<\/p>\nValidierungsabdeckung – Validation Coverage<\/h2>\n
Unabh\u00e4ngigkeit vom Review – Independence of Review.<\/h2>\n
Flexibilit\u00e4t und Verantwortlichkeiten<\/h2>\n
\nSoftware wird\u00a0 in einem breitem Spektrum an Umgebungen und f\u00fcr ein reiches Angebot an Ger\u00e4ten mit unterschiedlichen Risiken entworfen, entwickelt, validiert und reguliert.Medizinger\u00e4teanwendungen, die von der FDA reguliert sind, enthalten Software die …<\/p>\n\n
\nSoftwarevalidierungsaktivit\u00e4ten und -aufgaben k\u00f6nnen zerstreut an verschiedenen Stellen von verschiedenen Organisationen durchgef\u00fchrt werden. Jedoch, unabh\u00e4ngig der Verteilung, vertraglichen Beziehungen, Komponentenquellen oder der Entwicklungsumgebung bekommt der Ger\u00e4tehersteller und Spezifkationsersteller die absolute Verantwortlichkeit f\u00fcr die Sicherstellung, das Software validiert ist.<\/p>\nAktivit\u00e4ten und Aufgaben<\/h1>\n
Softwarelebenszyklusaktivit\u00e4ten<\/h2>\n
\n
\nFDA Glossar definiert:\u00a0Glossary of Computerized System and Software Development Terminology<\/p>\nTypische Aufgaben, die Validierung beg\u00fcnstigen<\/h2>\n
Qualit\u00e4tsplanung<\/h2>\n
\n
\n— Ausfallsicherheit
\n— Handhabbarkeit
\n— Usability
\n— …<\/li>\n