Wir bietet weltweite Beratung auf  vielen Gebieten und weltweite Beratung zur Arzneimittelentwicklung

Elektronische Systeme und Kryptographie

Sicherheit und Validierung von EDV Systemen: die Bedeutung von 21 CFR Part 11

Dr. Peter M. Kaiser

Die FDA hat 1997 einen Titel des Bundesgesetzwerkes Code of Federal Regulation (CFR), nämlich 21, Part 11, verabschiedet bzw. im Federal Register veröffentlicht und 2005 revidiert, der den Umgang mit und die Anforderungen an elektronische Dokumente und – soweit zutreffend – ihre Unterschrift in USA regelt, sofern kein Papierausdruck mehr erfolgt, der handschriftlich abgezeichnet wird. Der Geltungsbereich dieser Verordnung ist daher auf elektronische Dokumente und das Pendant zur handgeschriebenen Unterschrift, eben die elektronische bzw. digitale Unterschrift, beschränkt. Es besteht aber kein Zwang, solche zu verwenden. Werden lediglich mit Hilfe des Computers erzeugte Dokumente erstellt, die dann auf dem Papierausdruck unterschrieben werden, so ist man außerhalb des 21 CFR Part 11 (”typewriter approach”).

Im GCP-Umfeld sind elektronische Systeme traditionell bei der Datenerhebung, Datenevaluation und biometrischer (biostatistischer) Auswertung im Rahmen von klinischen Prüfungen zu finden; aber auch bei Dokumenten-Management-Systemen muß man darauf achten, daß diese validiert sind. Bei gekauften Systemen (vendor systems) müssen mindestens die Installations- und die Leistungsqualifizierung (IQ, OQ, PQ) vom Anwender als Teilvalidierung durchgeführt und eine Bewertung erstellt werden, warum ausgerechnet dieses System gekauft wurde; im Ernstfall sollte vorher ein Lieferantenaudit (”vendor audit”) durchgeführt werden, wobei dann vor allem dessen QM-System und die Validierungsdokumentation des Systems Hauptgegenstand sein sollte. EDC-Systeme (electronic data capture; auch remote data entry, RDE) werden eingesetzt, um in einer klinischen Prüfung beim Prüfarzt die Patienten-daten direkt in ein Terminal eingeben zu können, die dann in einen Datenbankserver übertragen werden. So wird unmittelbar die Datenbank generiert, aber der Prüfer fühlt sich in der Rolle als erster Dateneingeber nicht immer wohl. (Das Review obliegt dann dem Monitor, eine ganz neue Aufgabe!). Allerdings entfallen so die lästige handschriftliche Eintragung ins CRF sowie die Doppeleingabe vom Papier-CRF durch Hilfskräfte.

Weiter gibt es elektronische Projektmanagementsysteme, eReports über „Nebenwirkungen“ von Arzneimitteln (elektronische ICSR nach ICH Topic E2B), und elektronisches Zulassungsdossiers, eCTD, die ebenfalls Part 11 Anforderungen genügen und validiert sein bzw. verifiziert werden müssen.

FDA Title 21 CFR Part 11

Part 11 ist recht kurz und knapp gehalten, er umfaßt nur ca. 3 Druckseiten; jedoch ist im Federal Register auf ca. 35 Seiten die nahezu 10jährige Vorgeschichte der Entstehung und damit deren beabsichtigter Sinn und Zweck beschrieben. Dies ist unbedingt lesenswert.

Folgendes ist auf den drei Seiten beschrieben:

  • Die Definitionen von eRecords, eSignatures, digital signatures, handwritten signatures, open systems, closed systems; spezielle Zusatzbedingungen bei offenen Systemen (z.B. dem Internet bei Web-basierten Systemen)
  • Die Anforderungen an die mit diesen Begriffen verbundenen Systeme, wozu z.B. auch die Validierung gehört (zur Validierung von Computersystemen, CS, sind allerdings eigene Papiere der FDA verabschiedet worden).

Werden die Forderungen in den FDA-Definitionen zu eSignatur und digitaler Unterschrift (§ 11.3b) berücksichtigt, sind die allgemeinen Kriterien der Authentizität, Vertraulichkeit und Integrität von Daten erfüllt, die an eRecords gestellt werden. Die technische Realisierung ist offengelassen, wie übrigens auch vom deutschen Signaturgesetz (SigG); aber mit Hilfe von etablierten kryptographischen Methoden wie PGP oder GNU (kostenlos und kompatibel mit PGP) kann die Konformität mit diesen Anforderungen relativ leicht erreicht werden.

Anforderungen an die Validierung

Alle elektronischen Systeme müssen validiert sein, um jederzeit eine vertrauenswürdige Qualität, Glaubwürdigkeit und Sicherheit der Daten zu garantieren, die damit generiert werden. Jede Eingabe und jede Veränderung von Daten muß automatisch aufgezeichnet und dokumentiert werden (audit trail) sowie auf Anforderung ausgedruckt werden können. Der Zugang muß für autorisiertes Personal definiert und beschränkt sein (z.B. über ID und Password). Bei den Tests sollen vor allem auch Streßparameter eingesetzt werden, um die Robustheit des Systems zu erfassen. Alle Verfahrensweisen sollten in schriftlichen SOPs geregelt sein. Die Aus- und Weiterbildung des Personals über den Umgang mit elektronischen Systemen muß gewährleistet, bestätigt und dokumentiert sein.

Die Art der Validierung der verwendeten Software wird von der FDA zwar nicht vorgeschrieben, aber es haben sich die logischen Modelle, das V-Modell und das sog. Modell der 4Q (DQ, IQ, OQ, PQ) bewährt und sind anerkannt (siehe auch Seite “Systemvalidierung”).

Nach dem 4Q Modell wird so vorgegangen: es werden ein Projektteam gebildet, die Verantwortlichkeiten geregelt und der Validation Master Plan erstellt; als erstes wird die User Requirements Specification (URS) generiert, dann wird mit der Risikoanalyse begonnen, die begleitend fortgeschrieben wird. Es folgen darauf die Beschreibung des Design des Systems (DQ), Hardware und Software, und die Codierung/Programmierung durch den Softwareentwickler. Entsprechende Tests bei der Entwicklung („white box“ Tests) und die Versionierung werden ebenfall durch den Entwickler durchgeführt. Sodann werden die Software-Module, ggf. vorher die Hardware, zusammengesetzt (Installation, IQ), wieder getestet und schließlich das gesamte System mit Modelldaten getestet (OQ). Bei der letzten Testreihe werden „reale“ Daten verwendet und das System in realer Umgebung getestet (PQ); sie wird von einem designierten Anwender („user“) gegen die URS durchgeführt (User Acceptance Tests, UAT). Dazu müssen meist umfangreiche Test-Scripts erzeugt werden, die der Anwender abarbeitet. Sind die Tests erfolgreich und alle Fehler beseitigt, wird ein User Manual geschrieben und das System als validiert erklärt. Handelt es sich um ein gekauftes System, sollte man ein sog. “service level agreement”, SLA, vereinbaren, um den validierten Zustand aufrecht erhalten zu können (”maintenance”).

Alle Schritte müssen gut dokumentiert sein. Der gesamte Validierungsprozeß sollte nicht nur auditierbar sein, sondern auch tatsächlich regelmäßig auditiert werden; am besten ist ein QA-Verantwortlicher Mitglied im Validierungsteam.

Das deutsche „Bundesamt für Sicherheit in der Informationstechnik (BSI)“ hat ein „IT-Grundschutzhandbuch“ publiziert, in dem ebenfalls die kompletten Anforderungen beschrieben werden, allerdings mehr unter Sicherheitsaspekten (http://www.bsi.de ).

Kryptographieverfahren

Pretty Good Privacy (neuerdings: OpenPGP) und GNU

Die Programme PGP und Gnu sind für private Zwecke frei erhältlich; die Software kann von folgenden Adressen herunter geladen werden:

 www.gnupg.org. Mit dem BfArM kann man über Gnu kommunizieren, aber OpenPGP und Gnu sind kompatibel.

Das Schlüsselpaar kann auf jedem PC leicht erzeugt werden, wenn das entsprechende Programm heruntergeladen wurde: nach Eingabe der entsprechenden Instruktionen benötigt der Computer eine sog. „passphrase“ (sozusagen ein erweitertes Password, mindestens 8 Zahlen und/oder Zeichen) vom Anwender und erzeugt einen persönlichen, privaten (geheimen) und einen öffentlichen Schlüssel. Der geheime Schlüssel kann ausschließlich nur dann verwendet werden, wenn die Passphrase eingegeben wird und wird nur zum Decodieren von Nachrichten oder Dokumenten oder eben eSignaturen verwendet. Der öffentliche Schlüssel wird zur Verschlüsselung von Nachrichten oder Dokumenten verwendet, jedoch derjenige des Empfängers, der seinerseits ein Schlüsselpaar generiert hat. So kann der Empfänger die verschlüsselte Nachricht decodieren und lesen, anderenfalls nur man selbst.

S/MIME Verfahren (Secure Multipurpose Internet Mail Extension) und X.509 Zertifikat

S/MIME wurde ursprünglich von der Firma RSA Data Security, Inc. entwickelt, die das Patent auch bis 2000 innehatte (RSA sind die Anfangsbuchstaben der Mathematiker Rivest, Shamir und Adleman). Es basiert auf dem PKCS #7 Datenformat für Nachrichten und dem X.509v3 Format für Zertifikate. PKCS #7 basiert wiederum auf dem ANSI DER Format für Daten. S/MIME und OpenPGP verwenden MIME, um die Nachrichten zu strukturieren. Das Verfahren basiert auf dem ‘multipart/signed’ MIME Typ, der in der RFC 1847 in USA für unterschriebene Nachrichten beschrieben ist, die über das Internet gesendet werden.

S/MIME und OpenPGP sind beides Verfahren (protocols), um Nachrichten mit den Attributen Authentizität und Privatheit zu versehen. Jedoch unterscheiden sie sich in vielerlei Hinsicht und  sind nicht gegenseitig austauschbar. Einige kryptographische Algorithmen sind gleich zwischen den beiden Verfahren, aber andere unterscheiden sich sehr.

Zertifizierungsstellen (Certification Authorities, CA)

In Deutschland gibt es bereits eine Infrastruktur von Zertifizierungsstellen (CA) aufgrund des „Signaturgesetzes“. Dies sind Dritte Institutionen, die die Echtheit bzw. Identität von Sender und Empfänger bescheinigen. Die Zertifikate müssen jedes Jahr erneuert werden.

Anerkannte Zertifizierer sind z.Z.:

D-Trust GmbH (Berlin), VeriSign (USA), debisZERT (Bonn), Dr. Droste Internet Consulting (Leverkusen), TI Trust Center (Trier, FhG), ITSG Trust Center (Gesetzliche Krankenversicherung GmbH, Institut u.a. der AOK) u.v.a.

Die meisten privaten CAs sind inadäquat teuer. Auch ist nicht klar, mit welcher technischen Ausstattung man eUnterschriften erstellen soll bzw. wie man Zugang zu den Räumen und Systemen kontrollieren kann (PGP, chip/token card, biometrische Scanner oder Kombinationen aus verschiedenen Methoden).

Vor einigen Jahren wurde – mit zweijähriger Verspätung – das „Gesetz über Rahmenbedingungen für elektronische Signaturen“ vom Bundestag verabschiedet. Es stellt die Umsetzung des Europäischen Gesetzes dar. Praktische Erfahrungen im GXP Umfeld liegen allerdings nur wenige vor.

______________________________________

Weitere Literatur und Internet-links:

1. Karen Hue, Melvyn Rapprecht & Enrique Rafalin, Practical Implementation of 21 CFR Part 11, Eur. Pharmac. Contractor, August 2000, 88-90

2. Ed Gerck, Overview of Certification Systems: X.509, PKIX, CA, PGP & SKIP, in THE BELL, ISSN 1530-048X, internet: www.thebell.net/papers/

3. Rainer W. Gerling (Datenschutzbeauftragter der Max-Planck-Gesellschaft), Einführung sicherer E-Mail, DFN-CERT Publikation: 7. Workshop „Sicherheit in vernetzten Systemen“ (URL www.rainer-gerling.de)

4. Imc (internet mail consortium): S/MIME and Open PGP: http://www.imc.org/smime-pgpmime.html

5. Imc (internet mail consortium): Definitions, reports&presentations: http://www.imc.org/reports.html

6. FDA CDRH (Center for Devices and Radiological Health): General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0, January 11, 2002 (http://www.fda.gov/RegulatoryInformation/Guidances/ucm126954.htm).

risus. justo ante. Aliquam massa accumsan id porta. Donec Donec Curabitur diam