tutorial systemvalidierung - startseite · 2018-07-11 · Übersetzt aus: pic/s guidance „ good...

Tutorial Systemvalidierung

TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Version: V04 Datum: 15.05.2018

Systemvalidierung - Tutorial | TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Seite 1

Tutorial Systemvalidierung TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Ablauf

11:00 Begrüßung und Einführung • Vorstellung des Schulungskonzeptes Systemvalidierung (Modul 0) 11:30 Grundlagen der Systemvalidierung • Was ist Validierung? (Modul 1) • Warum Validierung? (Modul 2) 12:30 Mittagspause 13:30 Prozess der Validierung • Wie wird validiert (Modul 3) • Anforderungsspezifikation / Risikoanalyse (Modul 4) • Lieferanten-/Herstellerbewertung (Modul 7)

15:30 Kaffeepause 16:00 Aufrechterhalten des validen Zustands • Strukturiertes Testen (Qualifizierung) (Modul 5) • Systembetrieb (Modul 6) 17:30 Ausblick / Diskussion


Einführung Systemvalidierung Tutorial Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Einleitung

Software in klinischen Studien muss GCP-konform eingesetzt werden

sie muss diesbezüglich validiert sein Nachweis und Dokumentation der Systemvalidierung liegt

generell in der Pflicht des Systemeigners Systemvalidierung ist Pflicht des jeweiligen Verbundes


Frühere TMF-Projekte und Aktivitäten

Systemvalidierung – Erstellung eines Validierungspaketes (2003)

Service Level Agreements – Musterdokumente (2003)

IT-SOPs (2003)

Leitlinien IT-Dokumentation (2004)

Probleme:

Mangelnde Abstimmung

Kaum praktische Umsetzungen

Fehlender Erfahrungsaustausch


TMF Projekt Systemvalidierung II

Systemvalidierung II – Erstellung eines Validierungspaketes (2005-2007)

Ziel: Einsatz, Evaluierung und Erweiterung des Validierungspaketes

Systemvalidierungsmasterplan + 70 Dokumente (Checklisten, Musterdokumente, Vorlagen)

Konzept für Lieferanten Audit

Integration der IT-SOPs

Schulungsunterlagen (8 Module, versch. Zielgruppen)


Weitere TMF-Projekte

SOPs für Durchführung klinischer Prüfungen (AG MKS)

Gesamtzeitraum 2005-2009, 68 SOPs

SOP-System – Dokumentenmanagementsystem (2009-2011)

BMBF-Projekt mit Beteiligung der TMF

Workshop Sicherheitskonzepte (2007)

Workshop IT-Servicemanagement (2011)


Probleme

Validierungspaket in der TMF kaum bekannt

Umfang der Dokumente zu groß, nicht konsistent

Aktualität der Dokumente, Abdeckung

Kommunikation mit Behörden

Fehlende Beratungsangebote / Vorkontrollen

Schulungsangebote nicht bekannt


Dokumentenliste alt


Ziel

Bestandsaufnahme / Aktualisierung / Überarbeitung des Validierungspaketes

Bessere Zusammenarbeit mit Behörden, Berücksichtigung der Vorgaben

Angebote zur Beratung und Vorkontrollen

Schulungsangebote

Bessere Dissemination in den Verbünden


Dokumentenliste aktuell

SVMP / Validierungsplan Traceability Matrix SOP Risikoanalyse + Muster SOP Anforderungsspezifikation (AS) + SW & HW Spezifikation SOP Funktionsspezifikation (FS) SOP Lieferantenbewertung/-audit + Checkliste SOP Code Review SOP Installations Qualifizierung (IQ) SOP Operationale Qualifizierung (OQ) SOP Prozess-/Performance Qualifizierung (PQ) Betriebskonzept (Datenschutz/Datensicherheit,

Fehlermanagement, Konfigurationsmanagement) Inventarisierung (Hard-/Software, Versionen) SOP Change Management SOP Training


Motivation für Schulungskurs

Verbünde müssen wissen:

wie sind die Systeme zu validieren wie wird der validierte Zustand aufrecht erhalten Der Schulungskurs sollte auf die spezifischen Belange der Verbünde zugeschnitten sein:

unterschiedliche Zielgruppen: Entscheider, Validierungsteam, Anwender

fortschreitende Diskussion bzgl. regulatorischer Anforderungen, z.B. digitale Signatur, Risikomanagement

Wechselnde Verantwortlichkeiten und organisatorische Strukturen innerhalb der Verbünde und untereinander


Leitideen für die Gestaltung des Schulungskurses

Systemvalidierungsmasterplan (SVMP) als zentrales Dokument Berücksichtigung der besonderen Anforderungen der Verbünde

(z.B. Zusammenlegung von IQ und OQ, Durchführung der IQ durch den Systemlieferanten (Softwareprovider)

die PQ und die abschließende Systemvalidierung werde vom jeweiligen Verbund häufig retrospektiv durchgeführt

knappe Ressourcen und mehrfache Belegung von Rollen Vermeidung, dass GMP-lastige Konzepte aus der Industrie

geschult werden, die im akademischen Umfeld nicht durchführbar sind

Modularer, leicht aktualisierbarer Aufbau


Zielgruppenorientierung und Schulungsziele

Das Schulungskonzept: drei Ebenen (Zielgruppen)

Entscheider (Geschäftsführer Verbünde): Schulungsziel ist ein Management-Overview zur Systemvalidierung, der die Notwendigkeit, den Nutzen und Wirtschaftlichkeits-aspekte hervorhebt (Schulungsdauer etwa 1½ Stunden)

Validierungsteam (Fachverantwortliche): Schulungsziel ist das Verständnis der Logik der System-validierung (GAMP, V-Modell, Life Cycle) und das Validierungsvorgehen (SVMP, Validierungsplan, IQ, OQ, PQ) (Schulungsdauer etwa 1 - 2 Tage)

Nutzer des validierten Systems (Anwender): Schulungsziel sind Testplanung, Dokumentation, Change Control (Schulungsdauer variiert)


Verteilung der acht Module auf die Zielgruppen

Entscheider Fachverantwortliche Anwender

Was ist Validierung? (1) (1) (1)

Warum Validierung? (2) (2)

Wie wird validiert? (3) (3)

Risikoanalyse (4)

Strukturiertes Testen (Qualifizierung)

(5) (5)

Systembetrieb (Aufrecht-erhalten des validierten Zustandes)

(6) (6)

Lieferanten Bewertung Audit (7)


Module des Konzeptes (1) – (2)

(1) Was ist Validierung?

Begriff der Validierung Computerisiertes System Validierung in der TMF Validierung als Teil des QM Systemvalidierungsmasterplan

(2) Warum Validierung?

GCP Motivation / Vorteile der

Validierung Aufwand/Nutzen-Relation Gesetzeslage kosteneffektive Validierung


Module des Konzeptes (3)

(3) Wie wird validiert?

validierungspflichtige Systeme

Kategorisierung nach GAMP Rollen und Verantwortlich-

keiten nach GAMP Das V-Modell Lebenszyklusmodell Angepasstes V-Modell Verantwortlichkeiten des

Systemlieferanten Vendor-Audit Eigenentwicklungen

Software Design Spezifikation Projektmanagement Traceabilitymatrix SOPs, Deliverables gemäß

SVMP



(4) Risikoanalyse

Risikobasierter Ansatz Risikoanalyse Festlegung der Maßnahmen GCP-relevante

Daten/Dokumente Risikofaktoren

(5) Strukturiertes Testen (Qualifizierung)

Benutzeranforderungen Funktional- und Design-

Spezifikation Qualifizierung Lebenszyklus-Modell Regeln beim Testen Arten von Tests


Module des Konzeptes (6)

(6) Systembetrieb (Aufrechterhalten des validierten Zustandes)

Change Management: Ziele Erhaltung des validen

Systemzustandes Change Control-Prinzipien Konfigurationsmanagement Klassifizierung v. Änderungen Änderungsmeldungen Phasen internes Audit

Revalidierung Störungen und Wartung Support Sicherheitsmanagement



(7) Lieferanten Bewertung & Audit

Verfahren der Bewertung Ablauf Auswertung Verfahren zum Audit

(8) Ausblick & Diskussion

Erarbeitung: SVMP, SOPs (Qualifizierung, Sicherheitsmanagement,…)

Gemeinsame Durchführung von Audits durch die Verbünde

Gemeinsame Durchführung von Schulungen


Was ist Validierung? Systemvalidierung Tutorial (Modul 1) Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Inhalt

Begriff der Validierung

Computerisiertes System

Validierung in der TMF

Validierung als Teil des QM

Systemvalidierungsmasterplan


Validierung: Definition

„Validierung ist die Erbringung eines Nachweises, dass ein Prozess mit hoher Wahrscheinlichkeit dauerhaft ein spezifikations- und qualitätsgerechtes Produkt erzeugt.“

– FDA Guidlines on General Principles of Process Validation

„Wenn ein computergestütztes System an die Stelle eines manuellen Vorgangs tritt, dürfen weder die Qualität der Produkte noch die Qualitätssicherung beeinträchtigt sein.“

– Annex 11 zum EU GMP-Leitfaden

„Validierung eines computergestütztes Systems ist der dokumentierte Nachweis, dass das System den regulatorischen Anforderungen genügt und so arbeitet und in Zukunft arbeiten wird, wie es dies laut Spezifikation tun soll.“


Notwendigkeit der Validierung

Formale bzw. gesetzliche Anforderungen an eine Validierung von Computersystemen, die in klinischen Studien eingesetzt werden, ergeben sich aus: den Qualitätsstandards des jeweiligen Verbundes, dem EU GMP-Leitfaden, den GCP-Richtlinien der International Conference of

Harmonisation (ICH) und den Richtlinien der US-amerikanischen Food and Drug

Administration (FDA) und der EMEA


„Computerisiertes“ System: Definition und Einordnung

Übersetzt aus: PIC/S Guidance „GOOD PRACTICES FOR COMPUTERISED SYSTEMS IN REGULATED “GXP” ENVIRONMENTS “ (PI 011-2, 1 July 2004)


Computerisiertes System: Software

SOFTWARE ANWEISUNGEN UND MENSCHEN

GERÄTE UND AUSRÜSTUNG

HARDWARE (Firmware)

COMPUTERSYSTEM (Steuerungssystem)

KONTROLLIERTER PROZESS

COMPUTERGESTÜTZTES SYSTEM

BETRIEBS- UND SYSTEMUMGEBUNG (inkl. andere einzelne oder vernetzte computergestützte Systeme, andere

Systeme, Medien, Menschen, Geräte/Ausrüstung und Abläufe)

• Standardsoftware • Eigenentwicklungen • Schnittstellen, Makros • Kommunikationssoftware • Datenbank / DBMS • Drucker-/Scannertreiber • Betriebssystem etc.


Computerunterstützung klinischer Forschung

Nennen Sie Systeme in Ihrem Bereich:


Computergestütztes System

Komponenten: Hardware, Software und Netzwerk-Bestandteile Funktionen und assoziierte Dokumentation Komponenten unterliegen GCP-Regularien, falls sie auf die Datenqualität

und Datensicherheit und damit die Patientensicherheit in GCP-Studien Einfluss haben (= GCP-Kritikalität)

Kritische Elemente im GCP-Umfeld:

Nachvollziehbarkeit der Studienaktivitäten Rückverfolgbarkeit von Prüfmustern Zulassungsrelevante Daten und Dokumente Randomisierung, Entblindung Patientenbezogene Datenhaltung


Ansatz der Validierungspolitik

Alle Beteiligten haben ein einheitliches und konsistentes Vorgehen bei der Validierung, sie besitzen eine Validierungspolitik

Sie wollen einen einheitlichen Standard der Validierung in den Verbünden sicherstellen

Die notwendige Vorlagen für die Validierungsdokumentation werden gemeinsam erstellt

Alle Beteiligten unterstützen sich gegenseitig bei der Validierung


Validierung in der TMF: Überblick

Validierung speziell im Umfeld der TMF-Mitglieder – angepasst an die Verhältnisse

individuelle Software kommerzielle Softwarelösungen

SVMP = Systemvalidierungsmasterplan

Bietet das Gerüst für eine eingehende und konsistente Validierung in den Verbünden

Zeigt den Ansatz der TMF zur Validierung SVMP übergreifend für alle Verbünde und Systeme

VPs = (system-spezifische) Validierungspläne

Projektpläne für die Validierung von einzelnen Systemen beschreibt, was und wieviel zur Validierung getan werden muß Pro System ein VP


Validierung ist Teil des Qualitätsmanagements

Verbünde betreiben ein Qualitätsmanagement (QM-Handbuch, SOPs, Audit, etc.) Vorgaben für Computersystemvalidierung (SVMP, SOPs) als Detaillierung eines qualitätsgesicherten Umgangs innerhalb von GCP-Prozessen Datenmanagement und Datenfluss wird mit dem Prozess

zusammen validiert Die Regelungen für die Computersystemvalidierung ergänzen die

im QMH beschriebenen Prozesse bzw. SOPs


Validierungsprozess: Überblick

Validierungspolitik und Guidelines


Softwaresystem Studiensoftware



Aufrechterhaltung der Validierung

Change Control

Sicherheit

Internes Audit

Validierungsplan Validierungsplan Validierungsplan

Compliance- und Risikobewertung



Systemvalidierung Systemvalidierung Systemvalidierung

Validierungssupport Review der Validierungspraxis


Systemvalidierungsmasterplan: Aufbau des SVMPs

1. Zweck und Anwendungsbereich 2. Validierungspolitik 3. Rollen und Verantwortlichkeiten 4. Validierungsprozedur 5. Systemspezifikation 6. Systemklassifikation 7. Validierungsplan 8. Qualifizierung

– 8.1. Design Qualifizierung (DQ) – 8.2. Installations Qualifizierung (IQ) – 8.3. Operationale Qualifizierung (OQ) – 8.4. Performance Qualifizierung (PQ)

SOPs, Checklisten, Anhänge (z.B. Risiko Bewertung, Betriebskonzept, Training)



Ergänzungen zum SVMP der TMF je Organisationseinheit / Standort: Verantwortlichkeiten Inventarliste aller computergestützten Systeme, inkl.

Validierungsstatus Liste der zu verwendenden SOP's (übergreifende Regelungen

referenzieren) Terminplan für Validierungsaktivitäten (systemübergreifend)


Warum Validierung? Systemvalidierung Tutorial (Modul 2) Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Inhalt

Good Clinical Practice - GCP

Gesetzeslage

Motivation / Vorteile der Validierung

Aufwand/Nutzen-Relation

kosteneffektive Validierung


System Validierung (CSV) und GCP (1)

Die Verbünde verfolgen das Ziel einer qualitativ hochwertigen klinischen Forschung überwiegend auf der Basis der Good Clinical Practices (GCP)

eine GCP-gerechte Durchführung von Studien sicherzustellen, ist eine zentrale Forderung verschiedener Gesetze und Richtlinien

Validierung von computergestützten Systemen ist ein elementarer Bestandteil der Qualitätssicherungssysteme

Validierte Systeme sind die Voraussetzung für alle Arten von Klinischen Studien und Basis guter klinischer Forschung



AMG § 4 23) Klinische Prüfung bei Menschen ist jede am Menschen

durchgeführte Untersuchung, die dazu bestimmt ist, klinische oder pharmakologische Wirkungen von Arzneimitteln zu erforschen oder nachzuweisen … mit dem Ziel, sich von der Unbedenklichkeit oder Wirksamkeit der Arzneimittel zu überzeugen



Neu Klinische Prüfung § 40-42 (Phase I-IV) Angeordnete Wirksamkeitsprüfung (Phase IV) Angeordnete Unbedenklichkeitsprüfungen (Phase IV oder NIS

s.u.) Nichtinterventionelle Unbedenklichkeitsprüfungen, die vom

Inhaber der Zulassung auf eigene Veranlassung durchgeführt werden oder die … angeordnet wurden

Untersuchungen, die dazu bestimmt sind, Erkenntnisse bei der Anwendung zugelassener oder registrierter Arzneimittel zu sammeln (AWB)

Alle anderen nichtinterventionellen Studien (§ 4)



GCP-Leitlinie ICH Topic E 6(R2) 1.12 (in Kraft seit Juni 2017) When using electronic trial data handling and/or remote electronic trial data systems, the sponsor should:

• Ensure and document that the electronic data processing

system(s) conforms to the sponsor’s established requirements for completeness, accuracy, reliability, and consistent intended performance (i.e. validation).

ADDENDUM • The sponsor should base their approach to validation of such

systems on a risk assessment that takes into consideration the intended use of the system and the potential of the system to affect human subject protection and reliability of trial results.



• Maintains SOPs for using these systems. ADDENDUM • The SOPs should cover system setup, installation, and use. The

SOPs should describe system validation and functionality testing, data collection and handling, system maintenance, system security measures, change control, data backup, recovery, contingency planning, and decommissioning. The responsibilities of the sponsor, investigator, and other parties with respect to the use of these computerized systems should be clear, and the users should be provided with training in their use.



• Ensure that the systems are designed to permit data changes in such a way that the data changes are documented and that there is no deletion of entered data (i.e. maintain an audit trail, data trail, edit trail).

• Maintain a security system that prevents unauthorized access to the data. (e) Maintain a list of the individuals who are authorized to make data changes (see 4.1.5 and 4.9.3).

• Maintain adequate backup of the data. • Safeguard the blinding, if any (e.g. maintain the blinding during

data entry and processing).

ADDENDUM • Ensure the integrity of the data including any data that describe

the context, content, and structure. This is particularly important when making changes to the computerized systems, such as software upgrades or migration of data. Systemvalidierung - Tutorial | TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Seite 43

Gesetzeslage – Anforderungen

Rechtsgrundlagen, Normen, Standards: AMG, PharmBetrV, GCP-V ICH-GCP E6 EU–GMP-Richtlinie und –Leitfaden mit ergänzender Leitlinie

computergestützte Systeme (Annex 11) GAMP-Guide und APV Interpretation des Annex 11 PIC Guideline für computergestützte Systeme (PI-011) US-FDA - 21 CFR Part 11 (Electronic Records; Electronic Signatures) US-FDA - Guide to Inspection of Sponsors, CROs and Monitors US-FDA – Guidance for Industry “Computerized Systems used in

Clinical Trials” Stand von Wissenschaft und Technik

Aber: Validierung nicht nur um gesetzliche Auflagen zu erfüllen


Compliance mit Anhang 11 zum EG-Leitfaden der Guten Herstellungspraxis

• Der vorliegende Anhang gilt für alle Arten computergestützter Systeme, die als Bestandteil von GMP-pflichtigen Vorgängen eingesetzt werden. Ein computergestütztes System ist eine Kombination aus Software-und Hardwarekomponenten, die zusammen bestimmte Funktionen erfüllen. Die Anwendung sollte validiert, die IT Infrastruktur sollte qualifiziert sein.

• Wird eine manuelle Tätigkeit durch ein computergestütztes System

ersetzt, darf es in der Folge nicht zu einer Beeinträchtigung der Produktqualität, der Prozesskontrolle oder der Qualitätssicherung kommen. Dabei darf sich das Gesamtrisiko des Prozesses nicht erhöhen.

Electronic Records Management: Computer System Validierung als Grundvoraussetzung Risikobasierter Fokus auf unterstützte Prozesse Der kontrollierte Zugriff auf den „Record“ muss über den

gesamten Lebenszyklus gewährleistet sein Systemvalidierung - Tutorial | TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Seite 45

Anhang 11 zum EG-Leitfaden der Guten Herstellungspraxis (Allgemeines 1)

1. Risikomanagement Risikomanagement sollte über den gesamten Lebenszyklus des computergestützten Systems unter Berücksichtigung von Patientensicherheit, Datenintegrität und Produktqualität betrieben werden. Als Teil eines Risikomanagementsystems sollten Entscheidungen über den Umfang der Validierung und die Sicherstellung der Datenintegrität auf einer begründeten und dokumentierten Risikobewertung des computergestützten Systems basieren. 2. Personal Es sollte eine enge Zusammenarbeit zwischen maßgeblichen Personen, wie z. B. Prozesseignern, Systemeignern und Sachkundigen Personen, sowie der IT stattfinden. Alle Personen sollten über eine geeignete Ausbildung und Zugriffsrechte sowie festgelegte Verantwortlichkeiten zur Wahrnehmung der ihnen übertragenen Aufgaben verfügen.


Anhang 11 zum EG-Leitfaden der Guten Herstellungspraxis (Allgemeines 2)

3. Lieferanten und Dienstleister 3.1 … formale Vereinbarungen … in denen die Verantwortlichkeiten … eindeutig beschrieben sind. IT-Abteilungen sollten analog zu Dritten behandelt werden. 3.2 Kompetenz und Zuverlässigkeit des Lieferanten sind Schlüsselfaktoren bei der Auswahl eines Produktes oder eines Dienstleisters. Die Notwendigkeit eines Audits sollte auf einer Risikobewertung basieren. 3.3 Die bei kommerziell erhältlichen Standardprodukten bereitgestellte Dokumentation sollte durch Nutzer im regulierten Umfeld dahingehend überprüft werden, ob die Benutzeranforderungen erfüllt sind. 3.4 Die Informationen zum Qualitätssystem und zu Audits … sollten Inspektoren auf Nachfrage zur Verfügung gestellt werden.


Anhang 11 zum EG-Leitfaden der Guten Herstellungspraxis (Projektphase 1)

4. Validierung 4.1 Die Validierungsdokumentation und -berichte sollten … Lebenszyklus abbilden. … 4.2 Die Validierungsdokumentation sollte … Aufzeichnungen im Rahmen der Änderungskontrolle und Berichte über alle während der Validierung beo-bachteten Abweichungen beinhalten. 4.3 Eine aktuelle Liste aller maßgeblichen Systeme und ihrer GMP-Funktionen (Inventar) sollte zur Verfügung stehen. …. 4.4 Die Benutzeranforderungen sollten die erforderlichen Funktionen des computergestützten Systems beschreiben und auf einer dokumentierten Risikobewertung sowie einer Betrachtung der möglichen Auswirkungen auf das GMP System basieren. …


Anhang 11 zum EG-Leitfaden der Guten Herstellungspraxis (Projektphase 2)

4. Validierung 4.5 … alle erforderlichen Maßnahmen … um sicherzustellen, dass das System in Übereinstimmung mit einem geeigneten Qualitätsmanagementsystem entwickelt wurde. Der Lieferant sollte angemessen bewertet werden. 4.6 Für die Validierung … spezifisch angepasster computergestützter Systeme sollte ein Verfahren vorliegen, das die formelle Bewertung und Berichterstellung … während … des Lebenszyklus des Systems gewährleistet. 4.7 Die Eignung von Testmethoden und Testszenarien sollte nachgewiesen werden. Insbesondere Grenzwerte für System-/Prozessparameter, Datengrenzen und die Fehlerbehandlung sollten betrachtet werden. … 4.8 Werden Daten in ein anderes Datenformat oder System überführt, sollte im Rahmen der Validierung geprüft werden, dass der Wert und /der die Bedeutung der Daten … nicht verändert werden.


Anhang 11 zum EG-Leitfaden der Guten Herstellungspraxis (Betriebsphase 1)

5. Daten … Kontrollmechanismen für die korrekte und sichere Eingabe und Verarbeitung der Daten enthalten. 6. Prüfung auf Richtigkeit … manuell eingegeben.. zusätzliche Prüfung abgesichert werden. 7. Datenspeicherung 7.1 Daten sollten durch physikalische und elektronische Maßnahmen vor Beschädigung geschützt werden. Die Verfügbarkeit, Lesbarkeit und Richtigkeit gespeicherter Daten sollten geprüft werden. Der Zugriff … während des gesamten Aufbewahrungszeitraums gewährleistet sein. 7.2 … regelmäßige Sicherungskopien aller maßgeblichen Daten ... Die Integrität und Richtigkeit der gesicherten Daten … sollte während der Validierung geprüft und regelmäßig überwacht werden.



8. Ausdrucke 9. Audit Trails … Bei der Änderung oder Löschung GMP-relevanter Daten sollte der Grund dokumentiert werden. Audit Trails müssen verfügbar sein, in eine allgemein lesbare Form überführt werden können und regelmäßig überprüft werden. 10. Änderungs-und Konfigurationsmanagement 11. Periodische Evaluierung Jede Änderung an einem computergestützten System einschließlich der Systemkonfigurationen sollte kontrolliert und nach einem festgelegten Verfahren erfolgen. Computergestützte Systeme sollten periodisch evaluiert werden, um zu bestätigen, dass sie sich noch im validen Zustand befinden und die GMP-Anforderungen erfüllen.



12. Sicherheit 13. Vorfallmanagement 14. Elektronische Unterschrift 15. Chargenfreigabe 16. Kontinuität des Geschäftsbetriebes Wenn computergestützte Systeme kritische Prozesse unterstützen, sollten Vorkehrungen getroffen sein, um die fortlaufende Unterstützung dieser Prozesse im Falle eines Systemausfalls sicherzustellen 17. Archivierung Daten können archiviert werden. Diese Daten sollten auf Verfügbarkeit, Lesbarkeit und Integrität geprüft werden. … Systemvalidierung - Tutorial | TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Seite 52

US-FDA – Guidance for Industry “Computerized Systems used in Clinical Trials, 05/07” (1)

A. Study Protocols • Each study protocol should identify at which steps a computerized system will be

used to create, modify, maintain, archive, retrieve, or transmit data. • The computerized systems should be designed: (1) to satisfy the processes

assigned to these systems for use in the specific study protocol (e.g., record data in metric units, blind the study), and (2) to prevent errors in data creation, modification, maintenance, archiving, retrieval, or transmission (e.g., inadvertently unblinding a study).

B. Standard Operating Procedures • There should be specific procedures and controls in place when using

computerized systems to create, modify, maintain, or transmit electronic records, including when collecting source data at clinical trial sites.

C. Source Documentation and Retention • When original observations are entered directly into a computerized system, the

electronic record is the source document.



D. Internal Security Safeguards 1. Limited Access • Access must be limited to authorized individuals (21 CFR 11.10(d). 2. Audit Trails • The need for audit trails should be determined based on a justified and

documented risk assessment that takes into consideration circumstances surrounding system use, the likelihood that information might be compromised, and any system vulnerabilities.

3. Date/Time Stamps

E. External Security Safeguards • In addition to internal safeguards built into a computerized system, external

safeguards should be put in place to ensure that access to the computerized system and to the data is restricted to authorized personnel.



F. Other System Features 1. Direct Entry of Data • …incorporate prompts, flags, or other help features into your

computerized system to encourage consistent use of clinical terminology and to alert the user to data that are out of acceptable range.

2. Retrieving Data • The computerized system should be designed in such a way that

retrieved data regarding each individual subject in a study is attributable to that subject.

3. Dependability System Documentation • For each study, documentation should identify what software and

hardware will be used to create, modify, maintain, archive, retrieve, or transmit clinical data.



F. Other System Features 4. System Controls • When electronic formats are the only ones used to create and preserve

electronic records, sufficient backup and recovery procedures should be designed to protect against data loss.

5. Change Controls • The integrity of the data and the integrity of the protocols should be

maintained when making changes to the computerized system, such as software upgrades, including security and performance patches, equipment, or component replacement, or new instrumentation. The effects of any changes to the system should be evaluated and some should be validated depending on risk.

G. Training of Personnel


Compliance mit 21 CFR Part 11 (1)

1. Definition of Part 11 Records • Records that are required to be maintained under predicate rule

requirements and that are maintained in electronic format in place of paper format.

• Electronic signatures that are intended to be the equivalent of handwritten signatures, initials, and other general signings required by predicate rules.

What is a 'Predicate Rule'? Any requirements set forth in any FDA regulation (GxP: GLP, GMP, GCP, etc.). The predicate rules mandate what records must be maintained; the content of records; whether signatures are required; how long records must be maintained, etc.


Compliance mit 21 CFR Part 11 (2)

1. Validation • …that you base your approach on a justified and documented risk

assessment and a determination of the potential of the system to affect product quality and safety, and record integrity.

2. Audit Trail 3. Legacy Systems 4. Copies of Records • …that the copying process used produces copies that preserve the

content and meaning of the record. • …allow inspection, review, and copying of records in a human readable

form at your site using your hardware and following your established procedures and techniques for accessing records.

5. Record Retention • …that your decision on how to maintain records be based on predicate

rule requirements and that you base your decision on a justified and documented risk assessment and a determination of the value of the records over time. Systemvalidierung - Tutorial | TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Seite 58

Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz – SigG)

“elektronische Signaturen” sind Daten in elektronischer Form, die anderen elektronischen Daten beigefügt oder logisch mit ihnen verknüpft sind und die zur Authentifizierung dienen

fortgeschrittene elektronische Signaturen qualifizierte elektronische Signaturen Nicht in den üblichen EDC-Systemen, aber in Zukunft in

elektronischer Patientenakte


Problem

Anspruch Wirklichkeit


Motivation / Vorteile der Validierung

steigert das Verständnis und die Nachvollziehbarkeit von Prozessen (Daten, Systeme, Change Management, …)

erhöht Vertrauen der Anwender in das computergestützte System, Zuverlässigkeit

legt GCP-Risiken offen und ermöglicht vorbeugende Maßnahmen zur Reduzierung

ist ein entscheidender Wettbewerbsvorteil für die Durchführung von GCP-Studien und bei der Akquisition von Studien für die Pharmaindustrie

steigert die Sorgfalt im Umgang mit Daten und Dokumenten erhöht die Datensicherheit durch kontrollierte Systeme steigert die Arbeitseffektivität durch getestete und gesicherte

Abläufe Bedenke: Hoher Nachbesserungsaufwand bei Nicht-GCP-Compliance Systemvalidierung - Tutorial | TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Seite 61

Aufwand/Nutzen-Relation: ökonomisch sinnvoll

Validierte Systeme sind zwingende Voraussetzung für Profit-Studien:

Investitionskosten zzgl. ca. 20 % für (Erst-)Validierung bei der System-Entwicklung/-Einführung

Betriebskosten zzgl. ca. 10 %, um Systeme im validierten Zustand halten

Kostenreduzierung durch gemeinsames Vorgehen (TMF-geführte PG „Systemvalidierung“), z. B.

Lieferanten-Audit Schulungen gegenseitiges Internes Audit Gemeinsame Nutzung von Validierungsdienstleistungen der Systemanbieter Nutzung von Verbund übergreifender Validierungskompetenz Gemeinsame Nutzungskonzepte (Hosting, ASP, Technology transfer)


Aufwand/Nutzen-Relation: notwendige Ressourcen (1) personelle Ressourcen

„Wird nebenbei gemacht…“? Validierung benötigt ein Team, deshalb: Projektmanagement mit definierten Rollen / Verantwortlichkeiten

explizite Prioritäten nach GCP-Kritikalität setzen und im Team kommunizieren

infrastrukturelle Ressourcen

vorhandene Infrastruktur soll genutzt werden (evtl. gemeinsame Nutzung / Verbund-übergreifend)

Bereithalten einer Testumgebung für Entwickeln und Testen einer Studienimplementation, die klar von der Produktivumgebung getrennt ist.


Aufwand/Nutzen-Relation: notwendige Ressourcen (2)

Aufwand/Nutzen konkretisieren

für die Validierung eines Standardsystems braucht ein qualifiziertes Team je nach System-Komplexität ca. 8 – 25 MT (mit vorhandenen Templates für alle notwendigen Dokumente)

bei ungeschultem oder wenig erfahrenem Personal kann sich der Aufwand um den Faktor 2-3 erhöhen.

je ungleicher die Systeme desto mehr Ressourcen


Maßnahmen für eine kosteneffektive Validierung

Projektmanager bestimmen Validierungsaktivitäten (Prioritäten, Ressourcen) planen Verantwortlichkeiten regeln Aufgaben an Systemanbieter/Lieferanten übergeben generische Validierungsdokumente verwenden risikobasierten Ansatz zur Aufwandsreduzierung nutzen Erfahrungswissen der anderen Verbünde nutzen rechtzeitig den Projektmanager und das Validierungsteam

schulen Plattformen und IT-Infrastrukturen vereinheitlichen Standard-Software und Commercial off-the-shelf (COTS)

verwenden


Wie wird validiert? Systemvalidierung Tutorial (Modul 3) Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Inhalt

validierungspflichtige Systeme

Kategorisierung nach GAMP Rollen und

Verantwortlichkeiten nach GAMP

Das V-Modell Lebenszyklusmodell Angepasstes V-Modell Verantwortlichkeiten des

Systemlieferanten Lieferanten-Audit Eigenentwicklungen

Software Design Spezifikation Projektmanagement SOPs Deliverables gemäß SVMP Traceabilitymatrix


Validierungspflichtige Systeme

Zur korrekten Fokussierung der Validierungsaktivitäten muss in einem Verbund zu jedem Zeitpunkt bekannt sein, welche Computersysteme validierungspflichtig sind und welche nicht

Validierungspflichtig sind grundsätzlich alle GCP-relevanten Computersysteme, d.h. Computersysteme, die einen direkten oder indirekten Einfluss auf GCP-Daten haben

Vorausgesetzt wird: eine genaue Kenntnis der Systeme, ihrer Komponenten und Schnittstellen

Bewertung, nicht nur auf der Systemebene, sondern auch auf der Ebene der Komponenten und Schnittstellen ist notwendig

Die Verbünde besitzen zur Unterstützung der sicheren Durchführung ihrer klinischen Forschungsprozesse eine Sicherheitsinfrastruktur


Kategorisierung nach GAMP

Wegen der Komplexität der verschiedenen Computersysteme, die in klinischen Studien eingesetzt werden, hat ISPE / GAMP ein 5-stufiges Klassifikationsschema entwickelt

Es kann als Leitlinie dienen, Validierungsanforderungen der Komplexität des Systems zuzuordnen

Jede Kategorie hat ihre eigenen Validierungsanforderungen, die von minimalen Anforderungen für Kategorie 1 und maximalen Anforderungen für Kategorie 5 reichen


Die einzelnen Kategorien (1)

Kategorie 1 (Betriebssysteme): das sind etablierte, kommerzielle Betriebssysteme (BS).

Beispiele sind Linux, Windows und Unix. Applikationen laufen unter der Kontrolle dieser BS. Etablierte BS sind nicht Subjekt einer spezifischen Validierung

Kategorie 2 (Firmware): Instrumente und Kontrolleinheiten beherbergen oft Firmware.

Firmware ist die Kombination aus einem Hardware-Device, Computerinstruktionen und Daten, die als „Read only“ Daten im Instrument sich befinden

Wird seit GAMP5 nicht mehr verwendet


Die einzelnen Kategorien (2)

Kategorie 3 (Standard Software Pakete): allgemein vorhandene Standard Software-Pakete, die eine „Off-

the Shelf“ Lösung zu einem Prozess anbieten. Das Pakete ist nicht so konfiguriert, dass es die Prozesse selber definiert. Konfiguration ist limitiert auf die Etablierung der Run time Umgebung des Systems (z.B. Netzwerk)

Kategorie 4 (konfigurierbare Software-Pakete): Interfaces und Funktionen, die es erlauben, nutzerspezifische

Prozesse zu konfigurieren (z.B. SAP). Dies umfasst auch die Konfigurierung definierter Softwaremodule.

Kategorie 5 (Custom bespoken Software): wird gemäß den Anforderungen des Nutzers speziell für ihn

entwickelt.


Kategorien für Software und Validierung

Kategorie Komponententyp Validierungsansatz

1 Betriebssystem IQ

3 Standardsoftware

3a Allgemeine Standardsoftware IQ, OQ SOPs, Verwendungsbereich Tutorial

3b Spezielle Standardsoftware IQ, OQ SOPs, Verwendungsbereich Tutorial Herstellerbewertung

4 Konfigurierbare Softwarepakete IQ, OQ SOPs, Verwendungsbereich Tutorial Herstellerbewertung Jegliche kundenspezifische, individuelle Programmierung ist gemäß Kategorie 5 zu behandeln

5 Individualsoftware DQ, IQ, OQ SOPs, Verwendungsbereich Tutorial Hersteller-Audit


Besonderheit Standard-Softwarepakete

Standard-Softwarepakete bieten eine „Off-the-shelf“-Lösung für bestimmte Geschäftsprozesse.

Konfigurationsmöglichkeiten beschränken sich im Wesentlichen darauf, das System in seine technische Umgebung zu integrieren

Die Kategorie der Standard-Softwarepakete ist weiter zu differenzieren in allgemeine Standardsoftware und spezielle Standardsoftware

Aus diesem Grund wurde Kategorie 3 in die beiden Subkategorien 3a und 3b unterteilt: Unter die Kategorie allgemeine Standardsoftware (3a) fallen z.B.

Datenbankmangementsysteme oder Textverarbeitungssysteme Bei spezieller Standardsoftware (3b) handelt es sich um Branchensoftware, wie z.B.

Datenmanagementsysteme oder EDC-Systeme für klinische Studien

Die Validierungsansätze der beiden Softwareklassen unterscheiden sich in der Notwendigkeit einer Herstellerbewertung im Falle spezieller Standardsoftware.


Konfigurierbare Softwarepakete

konfigurierbare Softwarepakete: weitgehende Konfigurationsmöglichkeiten nicht nur bei der Integration des Systems in seine technische Umgebung, diese Systeme können sehr genau an die einrichtungsspezifischen Geschäftsprozesse angepasst werden

Konfigurationsmöglichkeiten reichen von der Deaktivierung nicht benötigter Funktionen über die Änderung benötigter Funktionen bis hin zur Programmierung zusätzlicher Module

Der Validierungsansatz umfasst neben einer Herstellerbewertung insbesondere die Sicherstellung der Erfüllung der Benutzeranforderungen unter besonderer Berücksichtigung des konfigurierten Geschäftsprozesse

Zusätzlich entwickelte bzw. stark veränderte Module fallen unter die Kategorie 5 und erfordern damit den maximalen Validierungsaufwand


Systemklassifikation

1-011-anhang-systemklassifikation-inventarisierung.xlsx


Rollenklassifikation (GAMP)

• Prozessinhaber

• Systeminhaber

• Fachexperte


Prozessinhaber

• Die Person, die letztlich für die Führung der Geschäftsprozesse verantwortlich ist.

• Diese Person ist normalerweise der Leiter der Funktionseinheit oder der Abteilung, die dieses System verwendet.

• Der Prozessinhaber muss verantwortlich sicherstellen, dass das computergestützte System und dessen Betrieb gemäß der anzuwendenden standardisierten Arbeitsanweisungen (SOPs) während seiner gesamten Einsatzdauer vorschriftenkonform und für den vorgesehenen Zweck geeignet sind.


Systeminhaber

• Die Person, die letztlich für die Verfügbarkeit, den Service und Instandhaltung eines Systems und für die Sicherheit der auf diesem System gespeicherten Daten verantwortlich ist.

• normalerweise der Leiter der Abteilung, die für den System-service und die Instandhaltung zuständig ist, obwohl die Rolle eigentlich auf den spezifischen Systemkenntnissen und nicht auf der Position innerhalb der Organisation basiert sein sollte.

• Der Systeminhaber ist dafür verantwortlich, sicherzustellen, dass das computergestützte System gemäß der SOPs unterstützt und gepflegt wird.

Die Verantwortlichkeit für die Kontrolle des Systemzugriffs sollte zwischen dem Prozessinhaber und dem Systeminhaber abgestimmte werden. In einigen Fällen kann der Systeminhaber auch der Prozessinhaber sein


Fachexperte (FE)

• Jene Personen mit spezifischer Fachkenntnis in einem speziellen Bereich oder Feld. Fachexperten sollten die Führungsrolle bei der Verifizierung computergestützter Systeme innehaben.

• Die Fachexperten sind zuständig für die Planungs- und Verifizierungsstrategien, die Festlegung der Akzeptanzkriterien, die Wahl der geeigneten Testmethoden, die Durchführung der Verifizierungstests.


Das V-Modell

Projektantrag(project initiation)

Anforderungs-spezifikation(user requirement

specification)

Funktional-spezifikation,

(functionalspecification)

Design-spezifikation

(system architecture)

fachl.Risiko-analyse Prototyping

Modul -entwurf

(module design)

System-konfiguration

(parameter initialization)

Programmie-rung

(coding)

Schnittstellen-entwurf

(interface design)

DesignQualifizierung

Installations-qualifizierung(integration test)

Operationale Qualifizierung(functionality test)

Lieferanten-auswahl(supplier selection)

System-auswahl

(system selection)

PerformanceQualifizierung(user acceptance

test)

Systembetrieb und -wartung

(use & maintenance)

Fortlaufende Überprüfung(system review)

Stilllegung(cancellation)

IQ

OQ

DQ

PQ

Validierungs- & Projektplan

techn.Risiko-analyse

R

R

R

R

RR

R

Test-planung

R


IT Lebenszyklusmodell



specification)






Modul -entwurf

(module design)



Programmie-rung

(coding)


(interface design)





System-auswahl

(system selection)


test)


(use & maintenance)



IQ

OQ

DQ

PQ



R

R

R

R

RR

R

Test-planung

R


Warum das Lebenszyklusmodell (Validation Life Cycle)?

Die Entwicklung, Implementierung und der Betrieb von IT-Systemen, die regulativen Anforderungen entsprechen müssen, erfolgen anhand des IT Lebenszyklusmodells (VLC). Dieses Modell gewährleistet:

dass das betreffende IT-System den Qualitätsanforderungen entspricht

dass sämtliche Aktivitäten entsprechend den SOPs durchgeführt und dokumentiert werden

dass die gesamte Systemdokumentation bei Änderungen - auch während der Entwicklung - konsistent bleibt.

(Der VLC entspricht dem Entwicklungs-Lebenszyklusmodell, dem sog. V-Modell, des GAMP-Leitfadens zur Validierung automatisierter Systeme in der pharmazeutischen Herstellung.)


Phase I: Planung und Anforderungen



specification)

Funktional-spezifikation


System-entwurf(system

architecture)

fachl.Risiko-analyse


System-auswahl

(system selection)


R

R

R

R

R

Anforderungs- spezifikation

WAS?

Risiko- analyse

Lieferanten- bewertung

(Audit) auch:

LASTENHEFT


Phase II: Spezifizierung und Realisierung

o de u gsspe at o

(use equ e e t spec cat o )

Funktional-spezifikation





Modul -entwurf

(module design)



Programmie-rung

(coding)


(interface design)

e e a teaus a(supp e se ect o )

System-auswahl

(system selection)


R

R

RR

RFunktional-/Design-

spezifikation WIE?

auch: PFLICHTENHEFT


Phase III: Planung und Durchführung von Tests

Prototyping

Modul -entwurf

)



Programmie-rung

(coding)


(interface design)

Design Qualifizierung


OperationaleQualifizierung(functionality test)

System-auswahl

)

e o a ce Qua e u g(use accepta ce

test)

Test-planung

R


Phase IV: Akzeptanztest und Inbetriebnahme

Prototyping

System-


-entwurfinterface design)

Design Qualifizierung


OperationaleQualifizierung(functionality test)

Performance Qualifizierung(user acceptance

test)


(use & maintenance)



IQ

OQ

DQ

PQ

Test-planung

R


Angepasstes V-Modell

Vom klassischen V-Modell der Computervalidierung aus GAMP kann für bestimmte GCP-Systeme abgewichen werden

Dabei können, basierend auf einer Risikobewertung, einzelne Phasen aus dem V-Modell zusammengelegt werden, z.B.: Vereinigung der Anwenderspezifikation (AS) und

Funktionale Spezifikation (FS) in der Traceability Matrix (= Liste der Nutzeranforderungen)

Kombination von IQ und OQ zur Systemqualifizierung durch den Softwareprovider

Zusammenfassung von OQ- und PQ-Tests Die Abweichungen vom V-Modell sind zu begründen und im

Validierungsplan zu dokumentieren!


Zusätzlich zu beachten für Eigenentwicklungen

Definition Tool (z.B. SDTM-Wandler, SAS-Macros)

Programmier-/Entwicklungsrichtlinien Modularisierung Fehlerbehandlung Code Review Detail-Spezifikation Testen auf Programm- und Modul-Ebene Change Management / Versionsverwaltung Qualifizierungsnachweise der Entwickler/Programmierer Programm-Dokumentation i.w.S. sind interne Entwickler wie externe Lieferanten zu

bewerten (Qualitätsstandards, Nachvollziehbarkeit)


Code Review

Careful review of source code and its documentation is especially important for assuring that process specifications, conditions, sequencing, decision criteria, and formulas have been properly incorporated into the computer program. (FDA Compliance Policy Guide 7132a. 15) Source Code Review sollte umfassen: Review durch unabhängige Person, die nicht an der

Programmierung des Tools beteiligt war Review soll sicherstellen, dass die Programmierung in

Übereinstimmung mit den Design Spezifikationen erfolgte Codierungsstandards wurden eingehalten „Dead Code“ wurde entfernt Source Code Review-Bericht wird erstellt


Need-to-have ?


Dokumentation der Validierung

Folgende Dokumente sind gegebenenfalls im Rahmen der Validierung zu erstellen: 1. Anwenderspezifikation 2. Funktionale Spezifikation 3. Hardware Design Spezifikation 4. Software Design Spezifikation 5. Traceability-Matrix 6. Systemklassifikation 7. Berichte zu Herstellerbewertungen 8. Hardware- Installationsprotokoll(e)

9. Netzwerkdiagramm 10. Hardware-Liste 11. Software-Installationsprotokoll(e) 12. Software-Liste 13. Ausdrucke ggf. während der Installation automatisch erstellter LOG-Dateien 14. IQ-Herstellertestskripte (durchgeführt und unterzeichnet) 15. OQ-Testskript(e) (durchgeführt und unterzeichnet) 16. PQ-Testskript (durchgeführt und unterzeichnet) 17. Validierungsbericht Auswahl je System und Festlegung im Validierungsplan


SOPs (Standard Operating Procedures)

Zentrales Instrument für Validierung Für jede SOP ist anzugeben, wer für ihre Erstellung, Prüfung und

Freigabe verantwortlich ist Betriebskonzept:

folgende Bereiche müssen abgedeckt werden

– Datenerfassung und –verarbeitung – Systemwartung – Backup, Recovery, Notfallplan – Sicherheit – Änderungskontrolle

Muster SOP


Projektmanagement: Teamzusammensetzung und Schulung (1)

Entwicklung des Personals: qualifiziertes Personal mit ausreichend Erfahrung sollte fähig sein Planung, Einführung, Betrieb, Anwendungsberatung

und regelmäßige Prüfung von Computersystemen durchzuführen Die Qualifikation des Personals wird gemäß Ausbildung,

Schulung und Erfahrung im Umgang mit Computersystemen beurteilt

Prinzip: Personal darf nur entsprechend seiner Ausbildung und seiner Kenntnisse beschäftigt werden

Responsibility Split (Situation in den Verbünden) Der Verantwortungsbereich des einzelnen soll schriftlich

festgelegt sein Qualität und Sicherheit sollten beim Betrieb durch das Personal

von Computersystemen immer berücksichtigt werden


Projektmanagement: Teamzusammensetzung und Schulung (2)

Für die Schulung des Personals, das mit Computersystemen zu tun hat, muss der Prozesseigner (häufig der Leiter des Verbundes) sorgen

Er muss dem Personal die Inhalte der Computersysteme betreffenden Richtlinien und behördlichen Anforderungen nahe bringen

Die Verantwortung für die Schulung betrifft auch Systementwickler in den Verbünden, Wartungs- und Supportpersonal und Personal, dessen Tätigkeit die dokumentierte Funktionsfähigkeit des Computersystems beeinflussen könnte


Projektmanagement: Ressourcen

Durch Projektorganisation effektiv und ressourcenschonend validieren Projektteam definieren Organisationsdiagramm erstellen Schnittstelle Projektteam und Qualitätssicherungsfunktionen

definieren Validierungsplan Projektergebnisse (Deliverables) definieren Projektmeilensteine definieren Projekttätigkeit festlegen Personal zuordnen Geplante Start- und Endtermine für jede Tätigkeit festlegen Tätigkeiten als Diagramm darstellen


Projektmanagement: Validierungsbericht

Die Validierung endet mit einem Validierungsbericht, der das Ergebnis der Validierung beschreibt und diskutiert, ob die Akzeptanzkriterien der Qualifizierung erfüllt wurden

Er gibt an, ob ein System freigegeben werden kann


Risikoanalyse Systemvalidierung Tutorial (Modul 4) Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Inhalt

Risikobasierter Ansatz Risikoanalyse Festlegung der Maßnahmen GCP-relevante Daten/Dokumente Risikofaktoren


Einleitung

Die Risikoanalyse ist ein zentraler Bestandteil der Validierung von computergestützten Systemen.

Sie trägt dazu bei, dass das System korrekt funktioniert und

sie identifiziert GCP-relevante Prozesse, Funktionen und Daten


Risikobasierter Ansatz

Eine umfassende Risikoeinschätzung ist die einzige Regelungsgrösse im Validierungsprozess! Wir analysieren Systeme, Daten / Dokumente, und Anwender Überall, wo wir geringe Risiken identifizieren, dürfen wir den

Validierungsaufwand reduzieren Die Risikobewertung regelt Testumfang und Testtiefe Voraussetzung: Die Risikobewertung ist nachvollziehbar und

dokumentiert

US Food & Drug Administration (FDA): Incorporate the most up-to-date concepts of risk management

and quality systems approach


Risikoanalyse - Ziel

Ziel der Risikoanalyse ist es, alle mit dem Betrieb des Systems verbundenen Risiken hinsichtlich Beeinträchtigung

der pharmazeutischen Sicherheit des Produkts, des Anwenders / Patienten, des Systems und der Datensicherheit zu erkennen, zu bewerten und Maßnahmen zur Reduzierung des Risikos festzulegen. Bedenke: In der Risikoanalyse werden stets die direkten Auswirkungen der Risikofälle betrachtet, also nicht: „wenn die Patientendaten unvollständig erfasst werden, dann könnte irgendwann ein Patient geschädigt werden“, sondern: „..., dann wird die Charge/das Prüfmuster mit falschen Daten deklariert und ausgeliefert“.


Risikoanalyse - Methode

Für die Durchführung der Risikoanalyse gibt es verschiedene Methoden: FMEA, FTA, HACCP u.a. Die gängigste ist die FMEA (Failure Mode and Effekt Analysis): Fehlermöglichkeits- und Einfluss-Analyse. Die FMEA berücksichtigt 3 Komponenten: Voraussetzung: Alle Prozesse und Funktionen sind beschrieben

Eintritts- wahrscheinlichkeit Erkennbarkeit

Auswirkung bei Eintritt des Risikos


Ablauf

Prozess- identifikation

GCP- Relevanz

Dokumentation Keine Validierung

Bewertung Wahrscheinlichkeit

des Fehlers

Bewertung Schwere

der Auswirkung

Zuordnung einer Risikoklasse

Bewertung Erkennbarkeit

Dokumentation des Risikos

Risikominderungs- strategie

Dokumentation Validierung

Nein Ja


Risikoanalyse nach GAMP (Simple Risk Assessment)

GAMP beschreibt einen einfachen 2-Schritt-Ablauf Auswirkung gg. Wahrscheinlichkeit | Risikoklasse Risikoklasse gg. Erkennbarkeit | Risiko-Priorität Wahrscheinlichkeit

Ausw

irkun

g

Risi

kokl

asse

unkritisch

Eher unkritisch

Eher kritisch

gele

gent

lich

häuf

ig

rege

lmäß

ig

Klasse 3

Klasse 2

Klasse 1

K2

K2 K2

K1 K2 K2

K2 K2

K3

K2

K3

K3

selte

n

K1 K1 K2 K2 kritisch

K3

K2

gele

gent

lich

häuf

ig

rege

lmäß

ig

Risiko 3

Risiko 2

Risiko 1

R2

R1 R2 R2

R2 R3

R3

R3

selte

n

R1 R1 R2 R2 K1

Erkennbarkeit


Bewertungsschlüssel

Stufe Auswirkung Eintritts-wahrscheinlichkeit

Erkennbarkeitkeit

1 unkritisch Geringe Funktions-beeinträchtigung; evtl. kleine manuelle Korrekturen an Daten erforderlich

selten Eintreten der Risikofalls bei genannter Fehlerursache ist selten (< 1 von Hundert)

regelmässig Entdecken der aufgetretenen Fehler ist sicher oder sehr wahrscheinlich; Entdeckung unmittelbar in derselben Transaktion oder gleich nach Ausführung; begleitende Prüfungen sind sicher

2/3 eher kritisch / eher unkritisch Datenintegrität gestört, Verfügbarkeit von Daten / Dokumenten unterbrochen, Funktionseinschränkungen

häufig / gelegentlich Gelegentliches Auftreten der Fehlerursache (>=1 und < 5 von Hundert)

häufig / gelegentlich Entdecken des Fehlers ist wahrscheinlich, aber erst in nachfolgender Transaktion oder durch andere Mitarbeiter oder in anderem Bereich

4 kritisch Verlust kritischer Daten / Dokumente; Funktionstüchtigkeit stark eingeschränkt; Patientensicherheit gefährdet

regelmäßig Fehlerursache tritt wiederholt auf (>= 5 von Hundert)

selten Entdecken des Fehlers ist weniger wahrscheinlich; unsichere / unzuverlässige Prüfungen


Festlegung der Maßnahmen

Höhe des Risikos Mögliche Maßnahmen

Niedriges Risiko • Mittels Schulungen oder organisatorischer Maßnahmen betroffene Anwender sensibilisieren und im Akzeptanztest (PQ) überprüfen

GxP-kritisches mittleres oder hohes Risiko

• White Box Test / Source Code Review durch den Systemlieferanten, wenn z. B. eine Gefährdung von Patienten möglich ist

• Modultest / Integrationstest / Gesamtsystemtest / Akzeptanztest

• Prozessqualität erhöhen durch z. B. organisatorische Änderung des Geschäftsprozesses, SOP’ s oder Tutorial

• Änderung der Funktionalen oder Technischen Spezifikationen, ggf. Redesign, z.B. Einbau von Plausibilitätsprüfungen, Sicherheitsabfragen etc.


Feststellung möglicher Risiken

Die Feststellung und Bewertung möglicher Risiken, die durch das IT-System entstehen könnten, erfolgt in mehreren Schritten: Je Prozessschritt / Funktion:

Mögliche Risikofälle (Fehlverhalten des Systems) auflisten Betroffene Datensätze/Belege zuordnen (Auswertungen, Reports, Etiketten

usw.) Mögliche Fehlerursache(n) analysieren Auswirkung / Gefährdung (Fehlerfolgen) ermitteln und festlegen, ob die

Folgen GCP-relevant sind Beurteilung der Höhe der Auswirkung Ermittlung der Eintrittswahrscheinlichkeit Definition der Risikoklasse Wahrscheinlichkeit der Entdeckung Definition der Risikopriorität Festlegung der Maßnahmen


GCP-relevante Daten/Dokumente (lt. FDA)

Source Data Medical history information Medical examination results All lab results Demographic data: DoB -sex -weight Age -race -height Concomitant meds Patient ID number Study number Drug dispensing info Informed consent IRB approval Visit dates Intercurrent illness

Quelldaten Med. Historie Med. Untersuchungserg. Alle Labor-Ergebnisse Demografische Daten GD - Geschlecht - Gewicht Alter - Herkunft - Größe Begleitmedikationen Patienten-ID Studien-Nummer Darreichungsform /-menge Zustimmung des Patienten IRB*-Bestätigung Besuchstermine Begleiterkrankung

Data should be

attributable, original, accurate,

contemporaneous and legible

zuordenbar ursprünglich genau / exakt

direkt / zeitnah lesbar / erkennbar


Beispiele zu Risikofaktoren: Daten/Dokumente (1)

Aufzeichnungen, Datensätze, Dokumente, die GCP-relevante Informationen beinhalten: Trial Master Files (TMF) Study Reports Scientific Reports, Quality Reports, CMC Summaries, Inhaltsverzeichnisse Patientenberichte mit schwerwiegenden Nebenwirkungen

(SAE-CRF) Anträge, Vordrucke/Formulare (Application Forms) Drug Master Files (DMF)


Risikofaktor: Daten/Dokumente (2)

weitere Daten / Dokumente, die GCP-relevante Informationen beinhalten:

Anträge im Rahmen der Medikamentenentwicklung (Beantragung von klinischen Studien, INDs)

Task Reports (ggf. mit Referenz auf Laborbuch, Rohdaten) Patientenberichte (CRF-Case Report Form) jährliche Berichte (Annual Reports) Periodische Berichte zur Arzneimittelsicherheit (PSUR) Änderungsanträge (Variations) Herstellanweisungen und –berichte für Prüfmuster (Batch Records) Validierungs- / Qualifizierungsberichte SOPs, Verfahrens- und Arbeitsanweisungen Informationspakete für Behörden (Briefing Packages) Zusatzinformationen zu Methoden, Berichten, ... Renewals, Line Extensions


Risikofaktor: Anwender

mangelndes Training „öffentliche“ Passwörter unklare Verantwortlichkeiten Work-arounds sind bequemer Nicht praktikable oder zu allgemeine Anweisungen Fehlende Plausibilitätsprüfungen Fehlende Sicherheitsabfragen Bedenke: Vorsätzliche Manipulation

lässt sich nicht vermeiden

problem exists between keyboard and chair


Beispielformular: Risikofälle und Bewertung

Nr. ID Risikofall System Funktion

Ursache Gefährdung Auswirkung

Aus-wirkung U-EU-EK-K

Eintritts-wahr-schein-lichkeit N-M-H

Risiko-klasse

Erkenn-barkeit H-M-N

Risiko-priorität

Maß-nahmen

1 A1 A2 A3 A4 A5 A5 A6 A5 A6 A7

2

3

4

[A1] Referenz, ggf. Nr. aus Anforderungsspezifikation (AS) oder Funktionalspezifikation (FS/DS) [A2] Kurze Benennung des Risikofalls oder Negieren der Spezifikation, z.B. Eingabe im falschen Datenformat [A3] Verschiedene Ursachen können zu unterschiedlichen Maßnahmen führen. Die Ursachen sind jeweils einzeln zu listen, da das eine bessere Referenzierung ermöglicht. [A4] ggf. „nicht GCP-kritisch“ ergänzen [A5] Unkritisch, Eher Unkritisch, Eher Kritisch, Kritisch [A6] 1,2,3 [A7] z.B. Test der Funktion y in OQ, Erweiterung der SOP, etc.


Zusätzliche Schritte

„Nebenwirkungen“: werden GCP-kritische Risiken analysiert, sind auch mögliche

Auswirkungen auf Auswertungen, Berichte (Reports), Kennzeichnungen (z.B. Etiketten) usw. zu prüfen

„Verpflichtungen“: Für die Erstellung und Aktualisierung der Risikoanalyse sind der

Systemeigner und/oder der Projektleiter verantwortlich


Lieferanten Bewertung & Audit Systemvalidierung Tutorial (Modul 7) Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Wie wird ein Lieferant beurteilt?

ID Hauptkriterium Erreichte

Punktzahl

Max.

erreichbare

Punktzahl

Erfüllungsgrad (%)

1 Qualität („Fehlerrate“; eigene Erfahrung mit dem Produkt)

2 Akzeptanz auf dem Markt

3 Image als Software Lieferant

4 Lieferzuverlässigkeit und Termintreue

5 Kooperations- und Servicebereitschaft

6 Produktpräsentation

7 Audits durch Dritte (Ergebnisse)

8 Lieferant Audit (Ergebnis)

Gesamterfüllungsgrad: Eges = Σ (Erfüllungsgrad) / 8

Grad der Erfüllung voll erfüllt nicht erfüllt

Punkte 10 8 6 4 0

Ist ein Punkt mit „Ja“ oder „Nein“ zu beantworten, so bedeutet „Ja“ 10 Punkte, „Nein“ 0 Punkte.


Beispiel Lieferantenbewertung

ID Hauptkriterium Erreichte

Punktzahl

Max.

erreichbare

Punktzahl

Erfüllungsgrad (%)

1 Qualität („Fehlerrate“; eigene Erfahrung mit dem Produkt) 8 10 80%

2 Akzeptanz auf dem Markt 8 10 80%

3 Image als Software Lieferant 8 10 80%

4 Lieferzuverlässigkeit und Termintreue 6 10 60%

5 Kooperations- und Servicebereitschaft 4 10 40%

6 Produktpräsentation 3 10 30%

7 Audits durch Dritte (Ergebnisse) 5 10 50%

8 Lieferant Audit (Ergebnis) 8 10 80%

Gesamterfüllungsgrad: Eges = Σ (Erfüllungsgrad) / 8 500% / 8 = 62,5%

Grad der Erfüllung voll erfüllt nicht erfüllt

Punkte 10 8 6 4 0

Ist ein Punkt mit „Ja“ oder „Nein“ zu beantworten, so bedeutet „Ja“ 10 Punkte, „Nein“ 0 Punkte.


Gesamtbewertung

Klassifizierung der Gesamtbewertung

Gesamterfüllungsgrad:

Eges (%)

Bezeichnung der

Klassifizierung

90 ≤ X 100 voll zufriedenstellend A*

80 ≤ X < 90 überwiegend zufriedenstellend AB*

60 ≤ X < 80 bedingt zufriedenstellend B

X < 60 nicht zufriedenstellend C

Lieferanten, die einen Gesamterfüllungsgrad von 80% bzw. 90% überschreiten, die aber in einem oder mehreren Hauptkriterien nur einen Erfüllungsgrad unter 75% erreichen, werden nicht als „überwiegend zufriedenstellend“ bzw. „voll zufriedenstellend“ (AB bzw. A), sondern eine Stufe niedriger (B bzw. AB) eingestuft.


Wichtig für die Gesamtbewertung: Sind Kriterien mit null Punkten bewertet, deren Nichterfüllung entscheidenden Einfluss auf die Produktqualität haben kann, so wird der Lieferant trotz zufriedenstellender Gesamtbewertung in die Kategorie „nicht zufriedenstellend“ herabgestuft. Lieferanten mit der Gesamtbewertung „nicht zufriedenstellend“ können als Lieferanten nur dann in Betracht kommen, wenn die Marktsituation (Monopolstellung) keine Alternative bietet. In diesem Fall muss die Qualitätskontrolle, gegebenenfalls zusammen mit der Qualitätssicherung, prüfen und entscheiden, welche zusätzlichen Sicherungsmaßnahmen erforderlich sind.


Hintergrund Lieferantenaudit

Ein Lieferant, der Software liefert, muss ebenfalls schriftliche Nachweise liefern, dass seine Software validiert ist. D.h., der gesamte Lebenszyklus (SDLC) muss beschrieben sein. Um das zu überprüfen, muss der Lieferant bewertet und/oder ggf. auditiert werden.


Verantwortlichkeiten des Systemlieferanten

Zu liefernde Dokumente: Zertifikate, Nachweis über die Verwendung eines QS-Systems, ggf.

Auditberichte Qualifikationsnachweis des Projektleiters (Systemlieferant) bzgl. Computer

System Validierung (21 CFR 11, GAMP, ...) Qualifikationsnachweis der Projektmitarbeiter (Systemlieferant) und

Sublieferanten für die vorgesehenen Aufgaben Funktionale Spezifikation Installationspläne und Dokumentation Konfigurationspläne und Dokumentation Schnittstellenbeschreibungen System-/Administrator-Handbuch Benutzerhandbuch, Schulungsunterlagen Testpläne und Dokumentation Versions-/Release-Freigaben Versions-/Release-Plan für die nächsten 12 Monate

Minimum ?


Hersteller- / Lieferanten-Audit

Voraussetzung für die Validierung von Software ab GAMP-Kat. 3b ist eine Bewertung des Herstellers / Lieferanten

Die Bewertung erfolgt gem. SOP „Lieferanten Audit“ wichtig: sich „ein Bild machen“ über die Zuverlässigkeit und

Qualität des Lieferanten ggf. Audit vor Ort

„Qualitätssicherungsvereinbarung“ (QSV) mit dem Lieferanten,

um Validierungstätigkeiten /-dokumente „einkaufen“ zu können, z.B. den unteren Bereich des V-Modells: Funktionale Spezifikation … bis OQ


Möglichkeiten für den Audit eines Software-Lieferanten

# Bewertung

1 Durch Referenzen außerhalb der TMF

2 Durch eigene Erfahrung mit dem Lieferanten

3 Durch eigene Erfahrung mit dem Produkt

4 Checkliste - Mail Audit (Selbstbeurteilungsfragebogen)

5 Follow-up durch Video oder Telefonkonferenz

6 Bewertung durch Audits von Dritten

7 Lieferanten Audit durch den Anwender, um das Qualitätssystem zu bewerten

8 Lieferanten Audits durch den Anwender für individuelle Produkte


Lieferanten Audit

Bewertung Kommentar

1 Durch Referenzen außerhalb des Verbundes/TMF

Nützlich, wenn keine Erfahrung außerhalb des Verbundes/TMF mit dem Lieferant vorhanden ist. Kriterien sind: • Akzeptanz des Lieferanten auf dem

Markt • Image des Lieferanten als

Softwarelieferant • Reputation für gute Produktqualität

2 Durch eigene Erfahrung mit dem Lieferant

Erfahrung kann von der Anwendung mit dem Lieferant des fraglichen Produktes oder anderer Produkte abgeleitet werden. Kriterien sind: • Qualität der Produkte (Fehlerrate) • Ansprechbarkeit im Fall von Fehlern

(Telefonanruf, On-site Visit, bug fix) Systemvalidierung - Tutorial | TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Seite 123

Lieferanten Audit

Bewertung Kommentar

3 Durch eigene Erfahrung mit dem Produkt

Nahezu gleich wie 2, jedoch genauer, da Software wahrscheinlich von denselben Personen entwickelt und unterstützt wie bei Neukauf.

4 Durch eine Checkliste „Mail-Audit“ Eigene Checkliste, von öffentlicher Organisation oder Liste von privatem Autor

5 Follow-up durch Video oder TK Man kann prüfen, ob Dokumente aus dem Mail-Audit existieren, schnell verfügbar sind und den entsprechenden Inhalt sowie die erforderliche Qualität besitzen.

6 Audits von Dritten Unabhängige Bewertung des Qualitätssystems und/oder der Produktentwicklung


Lieferanten Audit

Bewertung Kommentar

7 Lieferanten Audit (System) Gute Einsicht in das Qualitätsmanagement-System (QMS)

8 Lieferanten Audit (Programm) Gutes Bild, wie die Produktqualität beschaffen ist


Strukturiertes Testen (Qualifizierung) Systemvalidierung Tutorial (Modul 5) Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Inhalt

Spezifikation Benutzeranforderungen Funktional- und Design-Spezifikation Qualifizierung Lebenszyklus-Modell Regeln beim Testen Arten von Tests


Vor der Entwicklung: Spezifikation

Spezifikation der Benutzeranforderungen: Grundlage der Validierung eines Computersystems sind die

Benutzeranforderungen an das System Die SOP „Anforderungsspezifikation“ beschreibt die

Vorgehensweise im Detail Die Benutzeranforderungen werden in der ersten Spalte der

Traceability-Matrix referenziert Benutzeranforderungen bei Anschaffung eines „Off the Shelf“-

Produktes Lieferanten- und Produktauswahl

Unterschied Anwenderspezifikation, Funktionale und Designspezifikation


Spezifikation der Benutzeranforderungen

1. Anforderungen ! Keine Lösungen ! 2. eindeutig referenzierbar 3. widerspruchsfrei 4. redundanzfrei formulieren 5. prüfbar 6. Doppeldeutigkeiten vermeiden 7. Fachausdrücke vermeiden oder definieren 8. soweit möglich einer Kategorie zuordnen:

Pflicht (=KO-Kriterium), Standard / Norm / Gesetz, Wunsch 9. Das Verständnis der Anforderungsspezifikation muss durch ein

gemeinsames Review von Entwickler / Lieferant und Anwender überprüft werden (DQ)


Auswahlprozeß und Erfassung der Nutzer-anforderungen bei EDC-Systemen in den Verbünden

Beispiel für die Auswahl eines „Off the Shelf“-Systems: Anfang 2001 begann TMF-Projekt zur Implementierung

kommerzieller klinischer Studien-Software mit remoter Datenerfassungsfunktionalität innerhalb der Verbünde der TMF

Als Basis für die Softwareevaluation diente die Ermittlung der Benutzeranforderungen (AS) von KKS und KN und die Erarbeitung entsprechender Nutzerprofile

Auf Basis der Nutzerprofile wurde ein Anforderungskatalog für die Softwareprovider erstellt

AS enthielt 117 Fragen Anforderungen AS umfasste sowohl technische als auch personenbezogene

Ressourcen und Anforderungen


Funktional- und Design-Spezifikation

Die FS/DS ist die Dokumentation des Systems hinsichtlich Funktionen und benötigtem Equipment, die genügen, um die Anforderungen der Anforderungsspezifikation zu erfüllen.

Das Dokument enthält sowohl die Spezifikation der Funktionen des Systems als auch die des Designs, das zur Realisierung der Funktionalität gewählt wurde

Bei sehr komplexen Systemen kann es sinnvoll sein, die Funktional- und Designspezifikation auf mehrere einzelne Dokumente zu verteilen.


Software Design Spezifikation

definiert, mit welchen Softwarekomponenten (z.B. Betriebssystem, Groupware, DMS) die funktionale Spezifikation realisiert werden soll

Die einzelnen Komponenten werden hinsichtlich ihrer Funktionalität, ihres modularen Aufbaus, ihrer zugrunde liegenden Datenstrukturen und ihrer Interaktionen detailliert beschrieben

Die Software Design Spezifikation erfolgt im Anschluss an die Erstellung der funktionalen Spezifikation.


Hardware Design Spezifikation

definiert, mit welchen Hardwarekomponenten die funktionale Spezifikation realisiert werden soll

Die einzelnen Komponenten und ihre Interaktion werden detailliert beschrieben

Die Hardware Design Spezifikation wird im Anschluss an die Software Design Spezifikation durch das Projektteam erstellt.


Nach der Entwicklung: Qualifizierung

Stufen der Qualifizierung: DQ = Design Qualifizierung IQ = Installationsqualifizierung OQ = Operationale Qualifizierung (Funktionalität) PQ = Performance Qualifizierung (Benutzerakzeptanz)


Lebenszyklus-Modell (Validation Life Cycle)

Nachdem die Benutzeranforderungen, die Funktional- und die Design-Spezifika-tion erstellt sind, kann überprüft werden, ob das System entsprechend seiner Anforderungen konzipiert wurde: Designqualifizierung [design qualification, DQ]



specification)






Modul -entwurf

(module design)



Programmie-rung

(coding)


(interface design)





System-auswahl

(system selection)


test)


(use & maintenance)



IQ

OQ

DQ

PQ



R

R

R

R

RR

R

Test-planun

g

R

Designqual.


DQ

Die Design Qualifizierung umfasst den dokumentierten Nachweis, dass das System entsprechend seiner Anforderungen konzipiert wurde

Das Design Review überprüft die Anforderungsspezifikation, die Funktionalspezifikation und die Design-Spezifikation auf Vollständigkeit, Korrektheit und Konsistenz

ggf. sind die Risikoanalyse, der Lieferantenauditbericht oder weitere Dokumente des Lieferanten zu überprüfen

Die Freigabe des DQ-Berichts bildet das „Go“ für die Realisierung des Systems.




specification)






Modul -entwurf

(module design)



Programmie-rung

(coding)


(interface design)





System-auswahl

(system selection)


test)


(use & maintenance)



IQ

OQ

DQ

PQ



R

R

R

R

RR

R

Test-planun

g

R

Lebenszyklus-Modell (Validation Life Cycle): Installationsebene

Installationsqual.

Nachdem alle Elemente des IT-Systems (Hardware und Software) zusammengefügt werden, kann überprüft werden, ob das System gemäß den Entwurfs- bzw. Konfigurationsvorgaben arbeitet: Installationsqualifizierung [installation qualification, IQ]


IQ

Die „Installation Qualifizierung“ umfasst die dokumentierte Verifikation, dass ein Computersystem gemäß Spezifikation installiert und konfiguriert wurde

Installationsplan: Nutzung von Herstellerskripten vs. Eigenerstellung, z.B.

Installationsanleitungen Installationsprotokoll:

Verweis auf systemgenerierte Logfiles (ausdrucken!) bei mehrstufiger Implementierung ggf. mehrere Teilpläne/-

protokolle gem. Installationsreihenfolge erstellen ggf. Verteilung dokumentieren, Roll-out Pläne


Lebenszyklus-Modell (Validation Life Cycle): Funktionsebene

Durch einen funktionalen Systemtest wird überprüft, ob das IT-System in der vorgesehenen betrieblichen Umgebung alle Funktionen spezifikationsgemäß ausführt: Operationale Qualifizierung [operational qualification, OQ]



specification)






Modul -entwurf

(module design)



Programmie-rung

(coding)


(interface design)





System-auswahl

(system selection)


test)


(use & maintenance)



IQ

OQ

DQ

PQ



R

R

R

R

RR

R

Test-planun

g

R

Operationale Qualifizierung


OQ

Die Operationale Qualifizierung umfasst die dokumentierte Verifikation, dass eine Systemkomponente alle ihr zugeordneten und in der Funktional- bzw. Designspezifikation definierten Funktionen korrekt ausführt

Typische Durchführung von OQ: Testplan / Testskript erstellen und freigeben Testprotokoll wird während der Durchführung erstellt und von

mind. 2 Prüfern (Testern) unterschrieben Fehler aufzeichnen, bewerten und korrigierende Maßnahmen über

ein Change Management einsteuern




specification)






Modul -entwurf

(module design)



Programmie-rung

(coding)


(interface design)





System-auswahl

(system selection)


test)


(use & maintenance)



IQ

OQ

DQ

PQ



R

R

R

R

RR

R

Test-planun

g

R

Lebenszyklus-Modell (Validation Life Cycle): Leistungsebene

Der Akzeptanztest verifiziert, dass das komplette System und die durch das IT-System unterstützen Prozesse sich innerhalb aller vorgesehenen Betriebszustände wie vom Anwender erwartet verhalten: Performance Qualifizierung [performance qualification, PQ]

Performance Qualifizierung


PQ (1)

Die Performance Qualifizierung umfasst die dokumentierte Verifikation, dass ein Computersystem als Gesamtsystem alle Benutzeranforderungen erfüllt und in der Lage ist, innerhalb der übergeordneten Geschäftsprozesse im Routinebetrieb alle geforderten Funktionen korrekt auszuführen

Typische Durchführung von PQ durch Einsatz von Testfällen und unter Einbeziehung der zukünftigen Anwender

Folgende Dokumente sollten nach Abschluss der PQ minimal vorliegen: PQ-Plan / -Testskript erstellen und freigeben Traceability-Matrix mit PQ-Referenzen PQ-Bericht

ggf. ist die PQ unter Beachtung vordefinierter Auflagen in der Produktionsumgebung durchzuführen (kontrollierter Echtbetrieb)


PQ (2)

Für die Durchführung der Performance Qualifizierung bzgl. der Benutzeranforderungen an die Datenqualität sollten Testszenarien (‚Teststudien‘) entwickelt werden

Das Testszenario ist eine simulierter Anwendungsfall mit dem Ziel, die Grundfunktionen einer Studiensoftware strukturiert und standardisiert zu validieren

Das Testszenario ist an die eigenen Erfordernisse anzupassen (dokumentieren!)


Beispiel: Testskript für eData Management


Traceabilitymatrix

Die Traceabilitymatrix dient dem Qualitätsmanagement als Überprüfung, ob alle Nutzeranforderungen in den entsprechenden Phasen vollständig getestet wurden

Die Traceabilitymatrix besitzt mindestens folgende Spalten: Nr. (Nummer), Anforderung, Funktion, Ausführung der Funktion Risiko Datum Tester Signatur

1-020_vorlage_traceabilitymatrix.xlsx


Beispiel: Traceability Matrix

1-020_vorlage_traceabilitymatrix.xlsx


Regeln beim Testen

GCP-konforme Testprozeduren: Korrekturen mit Begründung/Kommentar und datierte Unterschrift eindeutige Referenzierung aller Testdokumente (Ausdrucke) vollständig und eindeutig ausfüllen Fehler protokollieren immer mind. 2 Personen

ggf. Überprüfung der Systemstabilität durch Heavy Load Testing (Stresstest)

Fehler über Change Management Prozeduren korrigieren und fehlerhafte Tests wiederholen

Tester müssen geschult sein, d.h. Anwenderschulung vor PQ


Arten von Tests

Normales Testen: Testfälle, die die funktionelle und strukturelle Integrität des Computer-Systems testen (z.B. normale Patientendaten)

Grenzwertiges Testen: das System soll zwischen gültigen und ungültigen Werten unterscheiden und falsche Werte erkennen.

Plausibilitätstest: überprüft Eingabefehler und unlogische Eingaben

Stresstest: überprüft die systembedingten Grenzen des computergestützten Systems und dokumentiert, dass es auch unter Belastung korrekt funktioniert.


Systembetrieb (Aufrechterhalten des validierten Zustandes) Systemvalidierung Tutorial (Modul 6) Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


Inhalt

Systembetrieb und Änderungen Change Control: Prinzipien Fehler- & Konfigurationsmanagement Change Control Verfahren Änderungsantrag Klassifizierung von Änderungen Erhaltung des validen Systemzustandes internes Audit Revalidierung Störungen und Wartung Support Sicherheitsmanagement


Phase im Lebenszyklus (V-Modell): Systembetrieb


Anforderungen an den Systembetrieb nach GAMP

Bausteine von Betrieb & Wartung (lt. GAMP5): Fortlaufende Überprüfung (Review) Risikoanalyse System und Prozess-Audits Änderungskontrolle und Konfigurationsmanagement Schulung der Anwender und Systembetreuer


Maßnahmen zur Erhaltung des validen Systemzustandes (Überblick)

Maßnahmen zur Änderungskontrolle müssen gewährleisten, dass Systemänderungen nur risikobewertet und dokumentiert durchgeführt werden (Jede Änderung = Risiko den validen Zustand zu verlieren)

Maßnahmen zur Systemsicherheit dienen der Gewährleistung der Vertraulichkeit, Integrität und Verfügbarkeit von Computersystemen

Maßnahmen zur Leistungsüberwachung dienen der Überprüfung, ob die von einem Computersystem durchzuführenden Prozesse in den für sie geforderten Zeiten bearbeitet werden können

Ein zuverlässiger Support ist eine unbedingte Voraussetzung für den kontrollierten Betrieb eines Computersystems

Der valide Systemzustand sollte über interne und externe Audits regelmäßig überprüft werden

Regelmäßige Schulung der Anwender und Systembetreuer


Was kann sich ändern? – Beispiele:

Neue Software-Versionen, Releases, Patches, Builds Änderung der Datenstruktur, z.B. nach Datenmigration oder

Bereinigung Änderungen von Teilen der Systemumgebung nach einem

Disaster Recovery Änderungen am unterstützten Prozess (Konfiguration,

Customization) und der Dokumentation & SOPs Anbindung anderer Module oder Software-Pakete Erweiterung des Systems (Sizing)


Blockade-Taktik

„Never touch a running system?“ Stand einfrieren Lernen mit Fehlern zu leben, ggf. SOPs schreiben Empfehlung: Lassen Sie keine Benutzer an das System! Schliessen Sie alle Computer weg!


Change Control: die Prinzipien

Durch ein funktionierendes Change Control-Management werden Änderungen der Software systematisch erfasst und über die Notwendigkeit einer begleitenden Validierung entschieden

Werden Fehler festgestellt, müssen diese mit einem Fehlerprotokoll an den entsprechenden Verantwortlichen gemeldet werden

Mit jeder wesentlichen Änderung des Systems oder der Installation einer neuen Komponente oder eines Upgrades muß eine IQ durchgeführt und dokumentiert werden

Change Control betrifft neben der Software, auch Änderungen der Hardware, Netzwerkänderungen, Änderungen der Dokumentation (z.B. Benutzerhandbuch) und Tutorialen

Change Control bezieht sich nicht nur auf Fehler, sondern auch auf Verbesserungsvorschläge


Change Control: Abgrenzung

Change Control (Änderungsmanagement)

Konfigurations -management

Fehler -management

Störungen des validen Zustands

Geplante System-Änderungen

Nutzungs-änderungen


Fehlermanagement

Jeder FEHLER, der nicht in den Validierungsdokumenten erwähnt wird, ist eine Störung des validierten Zustandes!

Fehlerbehebung = Änderung

Change Control Systemvalidierung - Tutorial | TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. Seite 158

Konfigurationsmanagement: Elemente

Hardware: Systemkomponenten spezifizieren Aufzeichnung (Logs) der Einstellungen und Modifikationen von

Komponenten Kontrolle von Zustand/Status, Vollständigkeit, Konsistenz und

Korrektheit/Kompatibilität von Komponenten

Software: Module / Komponenten, deren Funktionsumfang von

Administratoren über Systemparameter einstellbar ist Bausteine (Programme), deren Funktionsweise von

Administratoren oder Anwendern über Vorgabewerte (Basis-/ Stamm-/ Grunddaten) gesteuert werden kann


Konfigurationsmanagement: Richtlinien

Ziel: Alle Änderungen an der Konfiguration sollen koordiniert und kontrolliert werden Konfigurationsstatus Versionskontrolle Spezifizierung Konfigurationsbeurteilung Freigabe

Im Rahmen der Validierung werden die Systemteile definiert, die dem Konfigurationsmanagement

unterliegen sollen, und mögliche alternative Konfigurationen geprüft und freigegeben

(Konfigurationsrahmen)

Änderungen außerhalb des Konfigurationsrahmens unterliegen dem Änderungsmanagement (Change Control)


Erhaltung des validen Zustandes durch Change Control

Das Change Control-Verfahren stellt sicher: 1. alle planbaren Änderungen werden kontrolliert umgesetzt 2. das Lebenszyklusmodell wird gemäß dem system-spezifischen

Projekt-/ Validierungsplan angewendet 3. jede Änderung unterliegt einem Genehmigungsprozess 4. jede Änderung wird bezüglich ihrer Auswirkung auf das

Gesamtsystem bewertet (Risikoanalyse), 5. aus der Bewertung werden nachvollziehbare Maßnahmen

abgeleitet


Change Control: Änderungsanträge

Änderungsanträge bei geplanten Änderungen am System Jeder Nutzer des Systems kann eine Änderung beantragen Der Systembetreuer (oder das Change-Control-Team) erhält den

Antrag und bewertet die Änderung Durch den Prozessinhaber und die QA-Abteilung erfolgt die

Genehmigung oder Ablehnung Jede Änderung muss dokumentiert werden und von der Person,

die die Änderung durchgeführt hat, und der QA-Abteilung unterzeichnet werden

Testung der Änderung Systemfreigabe durch die Unterschrift des Prozessinhabers


Klassifizierung von Änderungen

Änderung Klassifizierung

Mögliche Maßnahme(n)

Austausch einfacher Standard-Komponenten, z.B. Drucker, Endbenutzergerät

gering Nachweis der Eignung des Gerätes. Funktionstest und Dokumentation des Austausches.

Hardwareerweiterung (Hauptspeicher, Platten-kapazität, weitere Drucker)

gering Nachweis der Eignung des/ der Elemente. Funktionstest und Dokumentation des Austausches.

Erhöhung der Benutzeranzahl für Betriebssystem, Applikation, Datenbank

mittel Belastungstest mit max. Anzahl User erneut durchführen. Dokumentation der Tests

Wesentliche Änderungen von Datenvolumina (Grenzwerte der Datenbank werden erreicht)

hoch Hoch: Upgrade oder Installation einer neuen DB. Abwicklung über Lebenszyklus, ab Anforderungs-spezifikation. Mittel: Erweiterung der Datenbankfunktionalität (User / Volumen) mit mindestens Prozessqualifizierung.


Change Control baut auf dem Validierungsprozess auf

Die Systemvalidierung erleichtert das Change Control Bei der Bewertung von Änderungen und der Definition von

Maßnahmen sind hilfreich: Validation Master Plan und SOPs Liste aller Systeme inkl. Bewertung der GCP-Relevanz Risikoanalyse des betreffenden Systems / Moduls Datensicherheits- und –sicherungskonzept (erste) Erfahrungen im Umgang mit Änderungen während der

Systemeinführung qualifizierte Mitarbeiter, die das System oder den Prozess kennen


Change Control ist die logische Fortsetzung der Computer System Validierung

Sicherheit & Nachvollziehbarkeit im laufenden Betrieb

Risiko-betrachtung

Training

VA / AA (SOP)

Verfahren V-Modell

Erhaltung des validen Zustandes


Konzept für internes Audit

die interne Überprüfung des Validierungsstandes in den Verbünden Überprüfung einer regelrechten und adäquaten Computer-System-

Validierung Nachprüfbar Dokumentiert


Internes Audit: Aufgaben

Festlegung der Verantwortung: Prozessinhaber und QS Festlegung der Zeit- und Ablaufplanung Festlegung der Prüfperiode Festlegung des Entscheidungsvorgangs Durchführung des Audits


Ziel und Aufbau des internen Audits

Das interne Audit hat das Ziel festzustellen, ob sich das System in einem validierten Zustand befindet und in Übereinstimmung mit den GCP-Vorschriften und den Grundsätzen des Verbundes betrieben wird

Teile des Audits: Validierung Betrieb Konfigurationsänderungen Offenstehende Aktionen des Validierungsberichtes frühere Auditberichte Belege für Instabilitäten oder Unsicherheiten im Betrieb Änderungen der Umgebung, Anforderungen oder Praxis Betriebsanweisungen (SOPs) Personal (Tutorial, Qualifikation) Systeminstandhaltung Datensicherung


Revalidierung

Die Notwendigkeit für erneute Validierung des Systems (Revalidierung) kann sich nach größeren Änderungen an der Hard- und Software eines Computersystems ergeben


Störungen und Systemwartung

Sowohl für routinemäßige vorbeugende Wartungsarbeiten als auch zur Behebung von Störungen sollen dokumentierte Verfahren vorhanden sein

Diese Verfahren sollen die Aufgaben und Verantwortlichkeiten des dazu eingesetzten Personals beschreiben

Wenn derartige Wartungsarbeiten Änderungen der Hardware und/oder der Software erforderlich machen, kann es nötig werden, das System erneut zu validieren.

Über alle Probleme oder bemerkten Unregelmäßigkeiten, die während des täglichen Betriebs des Systems aufgetreten sind, sowie über die daraufhin durchgeführten Maßnahmen, sind Aufzeichnungen anzufertigen und aufzubewahren


Businesskontinuitätsplanung

Kontinuitätspläne (Kontingenzplänen) sollen für Katastrophen-situationen erarbeitet werden

Unter Kontingenzplänen versteht man eher die technischen Vorgehensweisen und unter Kontinuitätsplanung die Vorkehrungen, die aus Verbundsicht notwendig sind

Es ist sinnvoll hier mit Szenarien zu arbeiten, die auf Katastrophenplänen basieren, die festlegen, in welcher Weise auf das Auftreten bestimmter Bedrohungen reagiert werden soll

Im Bereich der Softwaresysteme betrifft dies z.B. Feuer, Wassereinbruch oder Diebstahl im Rechenzentren / Serverraum


Service Level Agreement (ASP)

im Bereich der Bereitstellung von Studiensoftware (Hosting, ASP) gibt es verschiedenen Dienstleistungen zwischen einem Softwareprovider und einem Verbund

Hierbei kann ein Verbund auch als Softwareprovider (z.B. EDC-System, Pseudonymisierungsdienst, SAE-Management) für einen anderen Verbund auftreten

Diese Beziehungen werden durch SLA-Verträge geregelt Hierbei werden die Dienstleistungen im Detail geregelt Muster-SLA-Vertrag für Verträge zwischen zwei Verbünden


Aufbau eines Muster-SLA‘s

1 Service Level Agreements 2 Rechenzentrumsdienstleistungen 2.1 Remote Hands Service

2.2 Organisatorische Abwicklung und allgemeine Leistungen 2.2.1 Projektleitung, Service-Manager 2.2.2 <Hostinganbieter> User-Help-Desk und Service- Desk Leistungen 2.2.3 Security-Management (Plan - Do - Check – Act) 2.2.4 Service Requests 2.2.5 Change-Management 2.2.6 Emergency Changes 2.2.7 Wartungsfenster 2.2.8 Erweitertes Wartungsfenster 2.2.9 Notfallhandbuch 2.2.10 Ticket-System – Dokumentation von Betriebsereignissen 2.2.11 Reporting/Berichtswesen 2.3 Service-Level-Agreements 2.3.1 Verfügbarkeiten 2.3.2 Für Service-Level relevante Definitionen 3 Dezentrale Produkte 3.1 Hardware 3.2 Software 3.3 Störungsannahme 3.4 (Optional) Ticket-System 3.5 Reaktionszeiten 4 Mitwirkungspflichten des Kunden


Support für den Systembetrieb: Arten von Support

Ein zuverlässiger Support ist eine unbedingte Voraussetzung für den kontrollierten Betrieb eines Computersystems

Arten von Support: First Level-Support: (auch „User Help Desk“) ist die erste

Anlaufstelle für alle eingehende Unterstützungsfragen. Ziel ist das schnelle Lösen einer möglichst großen Anzahl von Problemen.

Second-Level Support: unterstützt den First-Level-Support, sowohl durch Weiterbildung am Arbeitsplatz als auch durch Übernahme komplexerer Anfragen.

Third-Level Support: setzt sich aus Spezialisten bzw. Mitarbeiter des Herstellers des Systems zusammen


IT-Sicherheit: Bestandteile

Etablierung von IT-Sicherheitsprozesse im Verbund Aufbau einer geeigneten Organisationsstruktur für IT-Sicherheit

(Verantwortlichkeiten, Rollen) Erstellung einer Übersicht über vorhandene IT-Systeme, mit

Risikoabschätzung für Sicherheit Erstellung eines IT-Sicherheitskonzepts Umsetzung des IT-Sicherheitskonzepts nach einem

Realisierungsplan Erstellung eines Schulungskonzepts für IT-Sicherheit Sensibilisierung der Mitarbeiter für IT-Sicherheit Aufrechterhaltung der IT-Sicherheit Erstellung von Managementreports zur IT-Sicherheit


Sicherheitsmanagement: notwendige Dokumente

Datenbestandsübersicht Datensicherungsplan Datensicherungsarchiv Benachrichtigungen Mitarbeiterverpflichtungen Restaurierungsvorgehen

Wichtig: Backup von Daten Datensicherungsplan


Sicherheitsmaßnahmen

Festlegung von Verantwortlichkeiten Datenträgerverwaltung Regelungen für Wartungs- und Reparaturarbeiten Vergabe von Zutrittsberechtigungen Vergabe von Zugriffsrechten Überprüfung des Software-Bestandes (Nutzungsverbot nicht freigegebener

Software) Regelung des Passwortgebrauchs Ordnungsgemäße Entsorgung von schützenswerten Betriebsmitteln

(Datenvernichtung) Prinzip: "Der aufgeräumte Arbeitsplatz" Reaktion auf Verletzungen der Sicherheitspolitik Datenschutzaspekte bei der Protokollierung Regelmäßige Kontrollen der IT-Sicherheitsmaßnahmen


IT-Sicherheit: Notfallvorsorge

Zur Vorbeugung beim Eintreten eines Notfalles (z.B. Brand, Wasserschaden, usw.), welcher die Verfügbarkeit von Daten und Technik beeinträchtigt, sind zusätzliche Maßnahmen erforderlich: Verfügbarkeitsanforderungen Notfallhandbuch Notfallübungen Verträge, Versicherungen Ersatzbeschaffungsplan Siehe: Kontingenzplan, Wiederanlaufplan


IT-Sicherheit: Systemausfall

Der Ausfall eines Computersystems bedeutet, das ein Computersystems längere Zeit nicht genutzt werden kann

Zum Zugriff auf Datenbestände während dieser Zeit ist ein Ersatzsystem, oder ein alternatives Verfahren zur Datenrepräsentation, bereitzuhalten

Auch für das Ersatzsystem sind Anforderungen an: Verfügbarkeit, Angemessenheit, Praktikabilität, Verlässlichkeit und Vollständigkeit zu stellen

es sollte ein Verfahren festgelegt werden, um das Computersystem wieder in seinen funktionsfähigen Grundzustand zu bringen

Systemfehler sollten im laufenden Betrieb vermieden werden Kontrollmaßnahmen zum frühzeitigen Erkennen von Systemausfällen

sollten etabliert werden


Ausblick & Diskussion Systemvalidierung Tutorial Version: V04 TMF - Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.


TMF-Angebot Systemvalidierung

3 voneinander unabhängige Leistungen/Pakete Schulung Beratung inkl. Unterlagen/Dokumente Audit

Jedes Paket kann im Prinzip von unterschiedlichen

Personengruppen durchgeführt werden Unterschiedliche Kompetenzen erforderlich Steuerung des Verfahrens durch Task Force „Validierung“ Berichte in die AG Erfahrungsgewinn


Vielen Dank für Ihre Aufmerksamkeit! Mehr Information: http://www.tmf-ev.de/


tutorial systemvalidierung - startseite · 2018-07-11 · Übersetzt aus: pic/s guidance „ good...

Documents