DGQ - Regionalkreis Hamburg 28. Februar Validierung von Geräten und Software im Bereich Pharma und Medizintechnik

Transkript

1 DGQ - Regionalkreis Hamburg 28. Februar 2006 Validierung von Geräten und Software im Bereich Pharma und Medizintechnik

2 -2 -

3 Validierung von Software im Pharmaumfeld Carsten Bierans DGQ - Regionalkreis

4 Themen! Vorstellung Werum Software & Systems AG! Motivation: Das regulierte Pharmaumfeld, GxP! Gesetzliche Grundlagen und Leitfäden! Begriffsdefinition: Validierung! Grundsätzliches, welche Systeme sind betroffen! Das Lebenzyklusmodel (V-Modell)! Dokumentation! Vertiefung: Entwicklung und unterstützende Tätigkeiten! Vertiefung: Testen! Rückverfolgbarkeit Traceability! Umfang der Validierung - wie viel ist nötig?! Warum Validierung - Gründe und Nutzen der Validierung -4 -

5 Vorstellung Werum Software & Systems AG -5 -

6 Werum Software & Systems AG Werum AG, Headquarters, Lueneburg, Germany Werum America Inc., Towaco, NJ, USA Gründung 1969, über 240 Mitarbeiter, seit 1995 ISO 9001 zertifiziert Unser MES-Kerngeschäft... Pharma, API & Biotech MES Manufacturing Execution Systems Enterprise Production Management Papierlose Produktion RFID Track & Trace Lösungen CAPA Lösungen -6 -

7 Was macht ein MES? Übergeordnete MES-Funktionen: Feinplanung, Produktionsvorschriften, KPI usw. Vorgaben für alle Produktions- Bereiche Material- Verfolgung Abarbeitung in der Produktion Labor Instandhaltung Electronic Batch Recording (EBR) Reporting Wareneingang Wareneingang Einwaage, Einwaage, Dispensing Dispensing Herstellung Herstellung Verpackung Verpackung Auslieferung Auslieferung Integrierter Gesamtablauf -7 -

8 Funktionsverteilung im Ebenen-Modell Unternehmensebene: ERP = Enterprise Resource Planning ERP ERP-Integration Produktionsebene: MES = Manufacturing Execution Systems MES Anlagen-Integration Feldebene: DCS = Decentralized Control Systems Anlagen mit Basisautomatisierung: DCS, SCADA, SPS -8 -

9 The only place in your plant that will still need paper. It really works

10 Motivation: Das regulierte Pharmaumfeld, GxP -10 -

11 Das regulierte Pharma- & Biotechumfeld Rechtliche Grundlagen - 21 CFR Part 820 -AMG - PharmBetrV -EU-GMP - Annex 11 Behördliche Anforderungen -21 CFR Part 11 - (Parts 210,211) Pharmaunternehmen (Computer) System MES Komp. Komp.? Leitfäden - PIC/S - GAMP Guide MES Lieferant Lieferung Erstellung MES -11 -

12 Forderung: GxP Anforderungen durch Gesetze, Normen und Regelwerke richten sich an:! Qualitätsmanagementsystem! Entwicklung, Inbetriebnahme und Betrieb! System Funktionalität GMP GxP Good Manufacturing Practice Good pharmaceutical Practice cgmp Current Good Manufactoring Practice -12 -

13 Grundlage der Validierung GMP Qualität muss hergestellt werden, sie kann nicht nachträglich in das Produkt hineingeprüft werden! -13 -

14 Gesetzliche Grundlagen und Leitfäden -14 -

15 EU GMP Leitfaden " Qualitätssicherungssystem " Personal " Räumlichkeiten und Ausrüstung " Dokumentation " Produktion " Qualitätskontrolle " Herstellung und Prüfung im Lohnauftrag " Beanstandung und Produktrückruf " Selbstinspektion " Annex 11: Ergänzende Leitlinie computergestützte Systeme -15 -

16 FDA: Title 21 Food and Drugs Title 21 CFR Food and Drugs FOOD AND DRUG ADMINISTRATION, DEPARTMENT OF HEALTH AND HUMAN SERVICES part 820 Quality System Regulation (Medical Devices) part 210 Current good manufacturing practice in manufacturing, processing, packing, or holding of drugs; general part 211 Current good manufacturing practice for finished pharmaceuticals part 11 Electronic records, electronic signatures CFR: Code of Federal Regulation -16 -

17 Pharmazeutische Inspection Convention (PIC) 1970: Übereinkommen 10 europäischer Länder zur gegenseitigen Anerkennung von Inspektionen betreffend die Herstellung pharmazeutischer Produkte 1983: Anpassung der Basic Standards of GMP an die WHO-GMP- Regeln PIC/S Guidance: Good Practices For Computerised Systems In Regulated GXP Environments Basis für GMP-Inspektionen Grundlage: EU-GMP Annex

18 GAMP Forum späte 80er und frühe 90er Jahre: " Regulatorische Richtlinien vorhanden, jedoch nur ungenau bei Inspektionen betrachtet " Nachfrage nach einheitlichen Interpretationen bei den regulatorischen Richtlinien, gesteigert durch Erhöhung der Komplexität bei automatisierten Systemen " Erforderlich wurde ein reger Informationsaustausch zwischen Pharmaindustrie und Lieferanten! Gründung 1991 durch Dr. David Selby! Entstehung der GAMP-Guidelines, aktuell: Version 4, Dezember

19 Zweck des GAMP Leitfadens Der Zweck des Leitfadens ist es, Firmen der Gesundheitsprodukte- Industrie aus den Bereichen Pharma, Biotechnologie und Medizingeräte darin zu unterstützen validierte und vorschriftgemäße automatisierte Systeme aufzubauen. Dieser Leitfaden gibt den Lieferanten automatisierter Systeme Anleitungen auf der Grundlage der Guten Praxis zur Entwicklung und Instandhaltung solcher Systeme für die Gesundheitsprodukte-Industrie

20 Aufbau des GAMP -20 -

21 Begriffsdefinition: Validierung -21 -

22 Validierung Beweisführung in Übereinstimmung mit den Grundsätzen der Guten Herstellungspraxis, dass Verfahren, Prozesse, Ausrüstungsgegenstände, Materialien, Arbeitsgänge oder Systeme tatsächlich zu den erwarteten Ergebnissen führen. EU GMP Leitfaden Herstellen eines dokumentierten Nachweises, nach dem mit mit einem hohen Maß an Sicherheit ein bestimmter Prozess dauernd ein Produkt liefert, dass vorgegebenen Spezifikationen und Qualitätsstandards entspricht FDA Guidelines on General Principles of Process Validation Validierung ist die formelle Dokumentation guter Systementwicklungspraktiken

23 Grundsätzliches, welche Systeme sind betroffen -23 -

24 Welche Systeme sind betroffen? Neue und existierende Computer gestützte Systeme, die Daten erfassen, sammeln, verarbeiten, übermitteln, speichern oder aufarbeiten, # die möglicherweise für eine Wirkstoff- oder Arzneimittel- Zulassung verwendet werden # im Zusammenhang mit der Herstellung, Kontrolle, Prüfung, Verpackung, Lagerhaltung oder Distribution von Wirkstoffen oder Arzneimitteln für Menschen oder Tieren verwendet werden -24 -

25 System-Elemente Validierungsanforderungen richten sich an: Software Funktionen der der Software Entwicklung der der Software Ausrüstung Hardware, Anlagen, Peripherie, Infrastruktur Dokumentation Lebenszyklus-Dokumente Verfahrensanweisungen (SOPs) Personal Mitarbeiter, Training, Zuständigkeiten Betriebsumgebung, Geschäftsprozesse -25 -

26 Grundsätzliches # Systemverantwortlich ist der System-Eigner # Validierung computergestützter Systeme erfolgt nach dem QM-System des Nutzers # Validierung ist für jedes System ein individueller Prozess # Validierung ist mehr als der Test von Software # Validierung muss die Risiken der Gesamtheit des computergestützten Systems und seiner Handhabung berücksichtigen Validierung ist ein Prozess, der über die komplette Projektlaufzeit von der ersten Planung bis zur Stilllegung abläuft. Es gibt keine validierte Software zu kaufen! -26 -

27 Die drei Gebote der Validierung # Du sollst alle Aktivitäten hinsichtlich eines Systems planen, dokumentieren und kontrollieren # Du sollst den Nachweis erbringen, dass Du Herr über den Entwicklungs-, den Betriebs-, und den Änderungsprozess Deiner Systeme bist # Du sollst das Risiko, das von den eingesetzten Systemen ausgeht, berücksichtigen Was nicht dokumentiert ist gilt nicht -27 -

28 Verantwortlichkeiten Nutzer/Kundenverantwortung Audit Lieferanten- Verantwortung Gesamtsystem- Entwicklung Software- Entwicklung Inspektor Kunde Werum Die Behörde " interessiert sich für das laufende Gesamtsystem beim Nutzer/Kunden " interessiert sich für die Feststellung des Kunden, dass die Softwareentwicklung nach den Standards erfolgt, die von Industrie und Lehre anerkannt werden (z. B. QM-System des Lieferanten z.b. nach ISO9001 oder 21 CR F 820) " interessiert sich im Wesentlichen nicht direkt für die Softwareentwicklung beim Lieferanten -28 -

29 Lebenszyklus als V-Modell -29 -

30 Lebenszyklus als V-Modell Risk based approach Betrieb Planung und Spezifikation Risikoanalyse Akzeptanztest OQ, PQ Entwurf Installation IQ Herstellung Test -30 -

31 Dokumentation -31 -

32 Company Wide Processes Der Magische Pfeil CSV Policy And Guidelines CSV Inventory And Overall Planning!!!! Specification and Design $ $!! Change Management Security Management Infrastructure Training Development and Testing Validation Plan And Documentation Vendor Rating Electronic Records And Signatures Department SOPs/Guidelines! Release and Operation Non project-specific QAand Management tasks validated V System $ Project-specific QA- and Management tasks Quelle: Concept Heidelberg, Dr. G. Generlich

33 Dokumente in der Planungsphase Planung und Spezifikation Lastenheft Pflichtenheft Risikoanalyse Betrieb Planung und Spezifikation Akzeptanztest OQ, PQ Entwurf Validierungsplan Lieferantenbewertung Freigaben Installation IQ Herstellung Test -33 -

34 Dokumente in der Entwurfsphase Entwurf Entwurfsspezifikation Betrieb Planung und Spezifikation Komponenten- Testspezifikation FAT-Testspezifikation Akzeptanztest OQ, PQ Entwurf Entwurfsüberprüfung Freigaben Installation IQ Herstellung Test -34 -

35 Dokumente in der Herstellungsphase Herstellung Betrieb Planung und Spezifikation Akzeptanztest OQ, PQ Review Source Code Entwurf Installation IQ Freigaben Herstellung Test -35 -

36 Dokumente in der Testphase Betrieb Test Planung und Spezifikation Akzeptanztest OQ, PQ Komponenten-Testreport FAT Testreport Entwurf Installation IQ Herstellung Test -36 -

37 Dokumente in der Installationsphase Installation Installationsplan Betrieb Planung und Spezifikation Installationscheckliste Installationsreport Akzeptanztest OQ, PQ Installation Qualification Entwurf Installation IQ Herstellung Test -37 -

38 Dokumente in der Akzeptanztestphase Akzeptanztest Betrieb Planung und Spezifikation SAT-Testplan SAT-Testreport Akzeptanztest OQ, PQ Operational Qualification Performance Qualification Validierungsbericht Entwurf Installation IQ Herstellung Test -38 -

39 Dokumente in der Betriebsphase Betrieb Betrieb Planung und Spezifikation Akzeptanztest OQ, PQ Entwurf Herstellung Change Management Instandhaltung Periodische Prüfung Abschaltung Test Installation IQ -39 -

40 Streng sequentielles Vorgehen Kunde Lieferant + Kunde Lieferant Kunde + Lieferant Pflichten -heft Technische Spezifkation / Handbücher Lastenheft Implementierung Probebetrieb Lieferant / Kunde IQ, OQ, PQ Abnahme Abnahme Test (FAT) Technische Abnahme (SAT) Qualifizierung Vor Eintritt in eine neue Phase ist jeweils mit einem Review die Vorgängerphase abzuschließen. Die Dokumente sind zum Gebrauch in der nächsten Phase freizugeben

41 Vertiefung: Entwicklung und unterstützende Tätigkeiten -41 -

42 Entwicklung und unterstützende Tätigkeiten # Zulieferer Kontrolle # Ausreichende Ausbildung, Schulung und Erfahrung der Entwickler # Codierung gemäß der Vorgaben und Richtlinien, definiert in SW-Entwurfsspezifikation Codierrichtlinien Konfigurationsmanagement # Kommentierung von Änderungen Wer, Was, Wann, Warum Immer Referenz auf behandelten SCR Beschreibung der Änderung # Entwicklertest # Durchführung Source Code Review -42 -

43 Vertiefung: Testen -43 -

44 Rahmenwerk für Spezifikation und Qualifikation Betriebliches Lastenheft anhand von Performance Qualification Validierungserhaltung Stilllegung Stilllegung Design Qualification Pflichtenheft, Risikoanalyse anhand von Operational Qualification Design- Spezifikation, Systemhandbuch anhand von Installation Qualification Implementierung Implementierung " Lastenheft auf betriebliche Anforderungen/Requirements beschränken! " Pflichtenheft auf funktionelle/geschäftsfallorientierte Beschreibung beschränken! " Designspezifikation auf das reine Design beschränken! -44 -

45 Testdokumentation zur Qualifizierung Design Qualification (Entwurfsqualifizierung, DQ) Dokumentierten Nachweis, dass das vorgeschlagene Design von Einrichtungen, Systemen und Geräten für den vorgesehenen Gebrauch adäquat ist. Installation Qualification (Installationsqualifizierung, IQ) Dokumentierter Nachweis, dass ein Systeme gemäß schriftlicher und genehmigter Spezifikationen installiert wurde. Operational Qualification (Funktionsqualifizierung, OQ) Dokumentierter Nachweis, dass ein System gemäß schriftlicher und genehmigter Spezifikationen innerhalb aller vorgesehener Betriebsbereiche arbeitet. Performance Qualification (Leistungsqualifizierung, PQ) Dokumentierter Nachweis, dass ein System in der Lage ist, die Prozessvorgänge, die es ausführen oder kontrollieren soll, gemäß schriftlicher und genehmigter Spezifikationen in seinem spezifizierten Anlagenumfeld auszuführen und zu kontrollieren

46 Testen: der Weg zur Systemvalidierung Werum Werum, Kunde Kunde (optional mit Unterstützung von Werum) Realisierung Testphase Qualifizierungsphase Entwickler -test Komponenten -test FAT SAT IQ OQ PQ SW Entwurfsspezifikation Pflichtenheft Pflichtenheft Systemhandbuch Lastenheft Projektlaufzeit -46 -

47 Wie viel soll getestet werden? Der IT Profi sagt Warum soll ich testen, ich weiß es ist in Ordnung Der Validierungs-Experte sagt Das kommt darauf an Der Berater sagt Testen Sie alles, wenn Sie keine Zeit haben machen wir das Der Inspektor sagt Sagen Sie mir bei der Inspektion wie viel sie getestet haben und ich sage Ihnen ob es mir reicht Der QA-Leiter sagt Alles testen, am besten zweimal. Bloß keine Unregelmäßigkeiten. Dann hab ich es in Inspektionen einfach Ihr Boss sagt Alles testen, aber fragen Sie nicht nach zusätzlichen Resourcen -47 -

48 Rückverfolgbarkeit - Traceability -48 -

49 Rückverfolgbarkeit - Traceability Wichtig: Die Verfolgbarkeit zwischen allen Phasen/Dokumenten muss gewährleistet sein! Die Schaffung der Verfolgbarkeit ist ein Vorgehen, das sicherstellt, dass: # alle Anforderungen erfüllt sind und zu den zugeordneten Designelementen verfolgt werden können # Anforderungen verifiziert sind und sich zu der Test- oder Verifikationstätigkeit verfolgen lassen -49 -

50 Verfolgbarkeit der Anforderungen Validierung Design Qualification (DQ) Planung and Spezifikation Anwender Lastenheft (URS) URS-ID Performance Qualification (PQ) URS-ID FAT Pflichtenheft (FS) FS-ID FS-ID Operational Qualification (OQ) FS-ID FS-ID SAT Tech.-Fkt-ID System Change Request (SCR) SCR Quellcode/ Source Tech.-Fkt-ID SW Entwurfsspezifikation DS-ID Komponententest Entwurfsdokumente Testdokumente Validierungsdokumente X Referenz mit Identifikation X -50 -

51 Umfang der Validierung Wie viel ist nötig? -51 -

52 Wie viel ist nötig?! Umfang und Aufwand der Validierung steht in direkter Beziehung zu Größe und Komplexität des Systems und seiner Anwendung! Gewählter Aufwand und das Vorgehen müssen schlüssig und plausibel darstellbar sein! Ein hohes Maß an Sicherheit ist zu erlangen! Entscheidungen sollen nach einer Risikoanalyse erfolgen Wald-freundlich oder Wald-unfreundlich -52 -

53 Software Kategorien (GAMP) Kategorie Softwaretyp Validierungsansatz 1 Betriebssystem Aufzeichnung der Version 2 Firmware Aufzeichnung von Version und Konfiguration, ggf. Kat. 5 3 Standard-Softwarepakete Validierung der Anwendung 4 5 Konfigurierbare Software Individuelle Software / Anwenderspezifisch Lieferantenaudit, Validierung der Anwendung, ggf. wie Kat. 5 Lieferantenaudit, Validierung des gesamten Systems Individuelle Programmierung als Kat.5 behandeln -53 -

54 Risikoanalyse Umfang der Validierung festlegen Verfahren der Risikoanalyse # Betrachtung der Funktionen (LH, PH) # Bewertung durch Experten (das richtige Team bilden) # Identifikation kritischer Prozess-Schritte # Klassifizierung des Risikos # Maßnahmen zur Risikominderung festlegen Risiko Bewertung # Mögliche Fehlfunktionen identifizieren # GMP-Auswirkungen analysieren # Eintrittswahrscheinlichkeit (Häufigkeit des Risikos) # Risikoklassifizierung # Entdeckungswahrscheinlichkeit # Risikopriorität Maßnahmen # Software Funktionen # Test (Breite/Tiefe) # Prüfungen (Parameter) # Verfahrensanweisungen FMEA Failure Mode and Effect Analysis

55 Warum Validierung Gründe und Nutzen der Validierung -55 -

56 Warum Validierung? Warum sich den Zwängen der Validierung aussetzen? Einige typische Aussagen: " Früher gab es so etwas nicht und die Systeme funktionieren heute noch " Dokumentation mache ich später, jetzt habe ich keine Zeit " Die zusätzliche Dokumentation bringt mir nichts, sie kostet nur Zeit und Geld " GMP = Give More Paper -56 -

57 FDA: 483/s Warning Letters Computer systems are not validated! Change management procedures for computer systems missing! Specifications are missing! Test documentation is incomplete! SOP for the validation of computer systems is missing! There is no validation plan! Risk analysis missing! Functionality does not comply with cgmp -57 -

58 Nutzen der System-Validierung Grundsätzlicher Vorteil der Validierung eines automatisierten Systems ist die Einhaltung der Vorschriften (compliance) # Besseres Prozessverständnis durch besseres Systemverständnis # Überwachung des Fortschritts von Projekt oder Anwendung # Systeme sind für ihren Zweck geeignet # Kürzere Projekt-Dauer # Einhaltung des Budgetrahmens # Anwenderanforderungen aktuell und auf längere Sicht erfüllt # Höhere Kundenzufriedenheit # Verbesserte Gewährleistung zu jeder Zeit # Einfache Instandhaltung und Wartbarkeit, geringere Stillstandszeiten # Niedrige Kosten für Unterhalt und Weiterentwicklung # Geringeres Risiko eines Misserfolgs # Sichern des persönlichen Erfolges -58 -

59 Vielen Dank für Ihre Aufmerksamkeit Fragen? Carsten Bierans Qualitätsmanager Werum Software & Systems AG Wulf-Werum-Straße Lüneburg Tel. +49 (0) 4131 / bierans@werum.de

60 Pharmaceutical Related Organizations Food and Drug Administration European Medicines Agency The Pharmaceutical Inspection Cooperation Scheme International Society for Pharmaceutical Engineering Concept Heidelberg, ECA -60 -

61 Law & Authority Guidance EU Guideline to Good Manufacturing Practice Medicinal Products for Human and Veterinary Use EU GMP Annex 11 Computerized Systems 21 CFR Parts 210, 211, 820, 11 FDA guide to inspection of computerized systems in drug processing Blue Book 83 General Principles of Software Validation; Final Guidance for Industry and FDA Staff January 11, 2002 Pharmaceutical cgmps for the 21st Century a Risk-Based Approach September 2004 Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices May 11, 2005

62 Organization s Guidance PIC/S Guidance Good Practices for computerized systems in regulated GxP environments 1 July 2004 GAMP 4 (Good Automated Manufacturing Practice) -62 -