|
Am 24. September 2001 hat die FDA zwei
Draft Guidances for Industry zu 21 CFR Part 11, Electronic Records,
Electronic Signatures, veröffentlicht. Der erste Guide enthält ein
Begriffsglossary zu 21 CFR Part 11. Viele der dort aufgeführten Begriffe
beziehen sich direkt auf 21 CFR Part 11. Für die Definition von
"Off-the-shell Software" bezieht sich der Guide auf die
Definition des FDA Center for Devices and Radiological Health: "A
generally available software component for which the user can not claim
complete software life cycle control". Die Validierung dieser
käuflichen Standardprogramme nimmt breiten Raum im 2. Draft Guidance zum
Thema Validierung ein. Näheres dazu finden Sie in diesem Artikel.
Zu den vielleicht weniger bekannten
Begriffen gehört die sog. "Regression Analysis and Testing".
Sie wird definiert als: "A software verification and validation task
to determine the extent of verification and validation analysis and
testing that must be repeated when changes are made to any previously
examined software products".
Größere Bedeutung wird zweifelsohne die
2. Guidance for Industry zum Thema "Validation" haben. Unter 5.1
wird die Bedeutung der "System Requirement Specifications" im
Rahmen der Validierung hervorgehoben. Die FDA sagt: "Without first
establishing end user needs and intended uses, we believe it is virtually
impossible to confirm that the system can consistently meet them".
Weiterhin wird zu "System Requirement Specifications"
ausgeführt, dass auch andere Faktoren, die nicht speziell in Part 11
benannt sind, einen Einfluss auf Electronic Records haben können. Deshalb
müssen auch für solche Faktoren "System Requirement Specifications"
erstellt werden.
Als Beispiel führt der Guide z.B. das
Scannen von Papierdokumentationen (z.B. Chargenprotokollen) auf. Hier ist
es erforderlich, die Auflösung, Geschwindigkeit, Farbgenauigkeit, die
Hardware und die Performance bezüglich deren Auswirkungen auf Electronic
Records zu bewerten. Ebenfalls sind die Anforderungen zu Scaleability (in
einer Netzwerkumgebung) und die Umgebungsbedingungen (z.B.
elektromagnetische Interferenzen und Temperatur/Feuchte) zu definieren und
demnach auch später im Rahmen der Validierung zu prüfen.
Unter 5.2 führt der Guide die
erforderlichen Dokumente zur Validierung eines Systems gemäß Part 11 an.
Benannt wird ein "Validation Plan" als "strategisches
Dokument", in dem definiert wird, was zu tun ist, wie der Zeitplan
der Validierung ist, welche Aufgaben ausgeführt werden müssen und wer
für die Validierung verantwortlich ist. Dieser Plan sollte wie die
anderen zwei Dokumente "reviewed and approved by designated
management" sein. Die "Validation Procedure" sollte
detaillierte Schritte zur Umsetzung der Validierung enthalten, dazu
gehört die Systemkonfiguration, Testmethoden und Akzeptanzkriterien inkl.
des erwarteten Ergebnisses. Schließlich sollte der "Validation
Report" die Ergebnisse der Validierung zusammenfassen. Wann immer
möglich, sollten hier quantifizierbare Größen anstatt
"bestanden/nicht bestanden" aufgeführt werden.
Unter 5.3 Equipment Installation ist
gefordert, dass vor Beginn der Validierung Hard- und Software richtig
installiert wurde und die erforderlichen Dokumentationen, z.B.
Benutzerhandbücher, SOPs, Spezifikationsblätter, etc., vorliegen.
Unter 5.4 "Dynamic Testing"
sind die Rahmenbedingungen für die Testdurchführungen aufgeführt.
Benannt sind: Testbedingungen (normale und Stressbedingungen),
Simulationstests (mit Simulationsprogramm) sowie Life user-site test
(unter den vorhandenen Nutzungsbedingungen des Systems). Die Tests selbst
werden in "Strukturelle Test" (white box testing), Funktionale
Test (black box testing) und Program Built Tests (Modul, Integrations- und
Gesamtprogrammtests) unterschieden.
Der Guide hebt hervor, dass Dynamic
Testing ein wichtiger Teil der Validierung ist, jedoch alleine keine
Validierung darstellt. Daher sind "Static verification
techniques", dazu zählt z.B. Source Code Reviews, unbedingt
erforderlich. Der Umfang der funktionalen Tests kann bei guten Ergebnissen
reduziert werden. Den Umfang der Validierung für ein Part 11 System
hängt wesentlich vom Risiko des Programms für Produktsicherheit,
Wirksamkeit und Qualität ab. Weiterhin sind die Risiken bezüglich
Datenintegrität, Authentizität und Vertraulichkeit sowie der
Systemkomplexität heranzuziehen.
Unter 5.7 ist die Unabhängigkeit des
Reviews gefordert, welches durch die Einbindung von externen Parteien
(Third Party) oder durch organisatorische Trennung erreicht werden kann.
Bezüglich des Change Control
(Konfigurationsmanagement) wird besonders auf die Überwachung der
Lieferanten und deren "Upgrades", "Fixes" bzw.
"Service Packs" abgehoben. Hier ist die Regressionsanalyse und
Regressionstest als "extremely important tool" benannt (siehe
Definition zu Beginn dieses Artikels).
Unter dem Punkt "Special
Considerations" sind ausführliche Anmerkungen zu sog. Commercial,
Off-the-shelf Software" gemacht worden. Deren
Validierungsnotwendigkeit wird durch das Statement "We do not
consider commercial marketing alone to be sufficient proof of a program's
performance suitability" ausgedrückt.
Auch wenn im folgenden gesagt wird
"However, the end user's validation approach for off-the-shelf
software is somewhat different from what the developer does".
Schwierig wird die Umsetzung der
Forderung unter 6.1.1 sein. Wenn möglich, sollte der Nutzer eine Kopie
der Anforderungspezifikationen des Entwicklers besorgen. (Das wird sehr
schwierig sein - Anmerkung des Verfassers)
Bezüglich der
Software-Strukturintegrität fordert der Guide, wenn der Source Code nicht
zur Prüfung verfügbar ist, die folgenden Maßnahmen einzuleiten:
1. Untersuchungen zur
Programmhistorie
und
2. "vorzugsweise"
Auditierung des Softwareherstellers
Bezüglich der funktionalen Tests von
Off-the-shelf Software wird ausgeführt, dass hier umfangreiche Tests
notwendig sind, wenn ein Review des Source Codes nicht möglich ist. (Das
wird die Regel sein – Anmerkung des Verfassers). Der zweite Punkt zu
"Special Considerations" befasst sich mit dem Internet,
insbesondere bei der Übertragung von Electronic Records. Als klares
Statement ist die Aussage: "We recognize that the Internet, as
computer system, cannot be validated because its configuration is
dynamic" zu verstehen.
Darauf ausbauend definiert der Guide,
dass es extrem wichtig ist, eine Validierung von Sender und Empfänger
unter besonderer Betrachtung der Genauigkeit, Vollständigkeit und
(recht)zeitigem Transfer von Daten und Records durchzuführen.
In den Anhängen zu dem Guide sind eine
Vielzahl von Publikationen zur Interpretation von Software benannt, die
Hilfestellung zur Umsetzung von 21 CFR Part 11 geben.
Wir hoffen, dass Ihnen diese
"persönliche" Kommentierung der Draft Guidance weiterhilft.
Download-Adressen:
http://www.fda.gov/cber/gdlns/esigglos.pdf
http://www.fda.gov/cber/gdlns/esigvalid.pdf
Veranstaltungen zu diesem Thema:
Electronic
Records / Electronic Signatures, 17. Januar 2002, Heidelberg
21 Cfr Part 11 Konferenz - Electronic Records / Electronic Signatures,
27./28. Februar 2002, Mannheim
Autor: Oliver Schmidt, CONCEPT HEIDELBERG
|
