1 / 34

Introduction to GAMP4

Introduction to GAMP4. IF IT’S NOT DOCUMENTED IT’S A RUMOUR!. GAMP Guide History. 1994 – UK Pharmaceutical Industry Computer System Validation Forum set up (now known as the GAMP forum) 1994 – First draft issued 1995 – Version 1 1996 – Version 2 1998 – Version 3 2001 – Version 4.

kara
Télécharger la présentation

Introduction to GAMP4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to GAMP4

  2. IF IT’S NOT DOCUMENTED IT’S A RUMOUR!

  3. GAMP Guide History 1994 – UK Pharmaceutical Industry Computer System Validation Forum set up (now known as the GAMP forum) 1994 – First draft issued 1995 – Version 1 1996 – Version 2 1998 – Version 3 2001 – Version 4 With GAMP4, the target audience has been expanded from just pharmaceuticals to the whole healthcare industry including biotechnology and medical devices. The scope has been expanded to cover automated systems within Good Clinical Practice (GCP), Good Laboratory Practice (GLP) and Good Distribution Practice (GDP) in addition to the original Good Manufacturing Practice (GMP) environment.

  4. Lots of Nasty Acronyms GCP GDP GLP GMP GxP URS VMP IQ OQ PQ SOP GCP Good Clinical Practice GDP Good Distribution Practice GLP Good Laboratory Practice GMP Good Manufacturing Practice GxP All of the above!! Sometimes cGxP with ‘c’ for ‘current’ URS User Requirements Specification VMP Validation Master Plan IQ Installation Qualification OQ Operational Qualification PQ Performance Qualification SOP Standard Operating Procedure

  5. Jargon for ‘project’ activities GAMP4 Validation Installation Qualification [IQ] Operational Qualification [OQ] Performance Qualification [PQ] GAMP4 – “Good Automated Manufacturing Practice” as defined in the GAMP4 Guide for Validation of Automated Systems. A set of guidelines for both users and suppliers – MORE LATER! Validation – “Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes” Installation Qualification [IQ] – “Documented verification that a system is installed according to written and pre-approved specifications”. Operational Qualification [OQ] -“Documented verification that a system operates according to written and pre-approved specifications throughout all specified operating ranges”. Performance Qualification [PQ] – “Documented verification that a system is capable of performing or controlling the activities of the processes it is required to perform or control, according to written and pre-approved specifications, while operating in its specified operating environment.

  6. Jargon continued… Calibration – “The set of operations which establish, under specified conditions, the relationships between values indicated by a measuring instrument, or values represented by a material measure or a reference material, and the corresponding values of a quantity realised by a reference standard.” Change Control – “A formal process by which qualified representatives of appropriate disciplines review proposed or actual changes to a computer system. The main objective is to document the changes and ensure that the system is maintained in a state of control.” Life Cycle Concept – “An approach to computer system development that begins with identification of the user's requirements, continues through design, integration, qualification, user validation, control and maintenance, and ends only when commercial use of the system is discontinued.” 21 CFR part 11 – FDA regulation covering the use of electronic records and electronic signatures – MORE LATER! Calibration Change Control Life Cycle Concept 21 CFR part 11

  7. Validation What is validation? “Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes” What needs to be validated? Pharmaceutical Process which produce drugs for the human and animal Consumption. • What is validated? • Process • Ensures that the process does what it supposed to do backed with documentary proof. Who is responsible for validation? The manufacturer is responsible for obtaining the validation.

  8. Validation.. What could be our responsibility? • Provide a system with documentary evidence that satisfies the Users requirement specification. • The system documentary evidence will be integrated into the overall process documentation which will be submitted for the process validation.

  9. Principle of validation • Document what is to be done • Document how it is to be done • Do it • Produce documented evidence that it was done in accordance with the “how” • Demonstrate that it remains in a state of control

  10. Where Does Process Validation begin? • Validate the API process beginning at the point where the structure of the active ingredient become evident. • Secondary Process • Packaging • Includes • Storage • Utilities • HVAC

  11. GAMP4 Structure • Principles and Framework • objectives of the Guide • overview of validation • validation lifecycle • IT systems • process control systems • benefits of validation • good practice definitions • glossary • source material. • Appendices • Management activities • validation planning/reporting • risk assessment • project change control, etc • Development activities • specification • code production • testing • Operating activities • service level agreements • performance monitoring • archive, etc GAMP principles and framework APPENDICES Management Development Operation GOOD PRACTICE GUIDES TRAINING MATERIALS

  12. GAMP Lifecycle Ongoing Operation Customer responsibility User Requirements Process Qualification Functional Specification Operational Qualification Joint responsibility Installation Qualification Software Design Hardware Design Integrated Testing Eurotherm responsibility Hardware Build Module Testing Configuration / coding

  13. GAMP and Traceability Update requirements documentation Document Control Document Control Re-Test Update configuration Configuration Control Functional Specification Operational Qualification FAULT Installation Qualification Software Design Hardware Design Integrated Testing Hardware Build Module Testing Configuration / coding

  14. GAMP4 Lifecycle – Planning and Definition Supplier Assessment (appendix M2) Covering both preliminary assessment and detailed supplier audit. Makes recommendations for audit planning and execution and also contains example checklists for both postal (preliminary assessment) audits and full supplier audits. • Validation planning (appendix M1) • Hierarchy of Validation Master Plans and individual system Validation Plans including: • GxP criticality assessment • validation strategy to cover the revised lifecycle model • formal list of validation deliverables • formal acceptance criteria for each lifecycle phase • formal detail of change control and document management procedures to be followed • formal list of SOP’s to be created or updated • Actions and procedures required to maintain the validated state after handover from project to ongoing operation D e s i g n R e v i e w T r a c e a b i l i t y M a t r i x C h a n g e C o n t r o l D o c u m e n t M a n a g e m e n t PLANNING AND DEFINITION • User Requirements Specification (Appendix D1) • Has to specify: • Operational requirements (process control, calculations, etc) • Data requirements (capacity, access, archive, etc) • Interfaces (operator, other equipment, plant) • Environment (layout, physical) • Constraints (timescales, compatibility with other equipment, etc) • Life Cycle (development / test requirements, deliverables, etc) Validation Plan Risk Assessment (Appendix M3) Covering risk assessment as part of the validation process. Initial risk assessment during URS generation to identify how much validation effort is required and which areas are critical to GxP product quality, safety, environmental protection, or business continuity. Review of the risk assessment during the design and development stage (to ensure that choice of supplier / implementation method has not introduced additional risks) Review of the risk assessment at completion of the design review prior to validation testing (to ensure that any problems identified or work-arounds implemented have not introduced additional risks). Once the system is in ongoing operation, risk assessment should form part of the ongoing change control strategy. The appendix also describes an example risk assessment process used to identify risks, categorise according to severity and likelihood and determine appropriate mitigation strategies. Design Review and Traceability Matrix (Appendix M5) Covering design review planning and deliverables. Typically, a review is required at the end of each specification stage. In order for the review process to be meaningful, a formal traceability of user requirements through to design documentation and tests carried out is required. An example traceability matrix format is provided. Change Control (Appendix M8) Change request, disposition and authorisation, completion and approval Document Management (Appendix M10) Production, approval, issue, change, withdrawal, records and storage Vendor Preliminary Assessment User Requirement Specification Risk Assessment + Critical Parameters Specification Approval Supplier Detailed Assessment KEY: User Responsibility Joint Responsibility Supplier Responsibility DESIGN AND DEVELOPMENT

  15. GAMP4 Lifecycle – Design and Development T r a c e a b i l i t y M a t r i x C h a n g e C o n t r o l D o c u m e n t M a n a g e m e n t Supplier Quality Plan D e s i g n R e v i e w DESIGN AND DEVELOPMENT • Quality and Project Planning (Appendix M6) • Plan needs to include: • User quality requirements (eg procedure references) • Supplier quality system (certification details, activities to be undertaken, and procedures controlling these, responsibilities for each activity) • Project Plan (eg Gantt chart) • Project organisation (contacts, project team names and titles, interface to QA) • Deliverable items (format, media) • Activities (milestones, start/end dates for activities, allocation of personnel) • Functional Specification (Appendix D2) • Specification replies to technical requirements from URS and needs to include: • Functional requirements (process control, calculations, etc) • Data requirements (capacity, access, archive, etc) • Interfaces (operator, other equipment, plant) • Non-Functional Attributes (availability, maintainability) • Hardware Design Specification (Appendix D3) • Needs to include: • Computer System (main computer, storage, peripherals, interconnections) • Inputs and Outputs (instruments used, accuracy, isolation, range, timing) • Environment (temperature, humidity, EMC, etc) • Electrical Supplies (filtering, loading, earthing, UPS, etc) • Software Design / Module Design Specifications (Appendix D4) • Need to include: • Software Design Specification • System Description (split into modules / interaction of modules) • System Data (files, databases, etc) • Module Descriptions • Software Module Design Specification • Module Overview (function, split into sub-programs) • Module Data (files, databases, etc) • Sub-Program Descriptions (language, standards, functions, parameters, etc) • Sub-Program Data (locally declared items) • Test Specifications (Appendix D6) • Need to include: • Scope of Tests • Overview and Test Plan (procedure for test execution, ordering of tests, personnel required, etc) • Test Requirements (hardware, software, test equipment, test software/data, documentation) • Test Scripts (unique reference, traceability to specification, pre-requisites, test instructions, data to be recorded, acceptance criteria, post test actions) Functional Design Specification Acceptance Test Specification • Software Production (Appendix D5) • Each module needs to address: • Identification (name, version, controlling specification, history) • Traceability (commenting of additions / deletions, cross reference to change source) • Programming Standards • Source code review attempts to ensure that programming standards are applied and that modules are in accordance with specifications. IQ Protocol Hardware Test Specification Hardware Design Specification Software Design Specifications Software Integration Test Spec OQ Protocol Software Module Specifications Software Module Test Specifications PQ Protocol Produce Hardware Produce Software KEY: User Responsibility Joint Responsibility Supplier Responsibility DEVELOPMENT TESTING AND SYSTEM BUILD

  16. GAMP4 Lifecycle – Testing, Build, Acceptance C o n f i g u r a t i o n M a n a g e m e n t D e s i g n R e v i e w T r a c e a b i l i t y M a t r i x C h a n g e C o n t r o l D o c u m e n t M a n a g e m e n t DEVELOPMENT TESTING AND SYSTEM BUILD Hardware Acceptance Testing Software Module Testing • Testing (Appendix D6) • Test procedure (documented in specification) needs to address: • Pre-requisites (availability of documentation, test equipment, test data etc) • Testing Philosophy (witnessing requirements, documentation and retention of results, indelible recording of results, etc) • Test Script Execution (what happens if acceptance criteria are met / not met?) • Test Results File (completed tests, documentation of test incidents / faults, etc) Integration Software Integration Testing DESIGN REVIEW AND ACCEPTANCE Factory Acceptance Testing KEY: User Responsibility Joint Responsibility Supplier Responsibility COMMISSIONING AND QUALIFICATION

  17. GAMP4 Lifecycle – Commissioning, Qualification C o n f i g u r a t i o n M a n a g e m e n t T r a c e a b i l i t y M a t r i x C h a n g e C o n t r o l D o c u m e n t M a n a g e m e n t COMMISSIONING AND QUALIFICATION Installation Qualification Installation Qualification [IQ] – “Documented verification that a system is installed according to written and pre-approved specifications”. Operational Qualification [OQ] -“Documented verification that a system operates according to written and pre-approved specifications throughout all specified operating ranges”. Performance Qualification [PQ] – “Documented verification that a system is capable of performing or controlling the activities of the processes it is required to perform or control, according to written and pre-approved specifications, while operating in its specified operating environment. Operational Qualification Validation Reporting (appendix M7) New material detailing best practice for validation reporting for both individual lifecycle phases and the final validation report. Performance Qualification Validation Report KEY: User Responsibility Joint Responsibility Supplier Responsibility ONGOING OPERATION

  18. GAMP4 Lifecycle –Ongoing Operation Appendix O5 – Performance Monitoring Guideline for parameters to be monitored (eg disk utilization, response times) and appropriate notification mechanisms. Appendix O6 – Record Retention, Archiving and Retrieval Guideline to address retention (security, indexing, availability during full retention period, etc) of all GxP records. Particular requirements for electronic record archival and retrieval. Appendix O7 – Backup and Recovery Guideline for data and software backups to guard against physical loss or accidental deletion. Appendix O8 – Business Continuity Planning Guideline covering broad issues of business continuity planning including risk assessment; disaster recovery procedures; contingency planning; emergency response planning; training; and rehearsal of the continuity plan. Appendix O9 – EU Guideline on Computerized Systems APV Specialist section interpretation of the Annex 11 ‘Computerized Systems’ points. Appendix O1 – Periodic Review Guideline for establishing whether validated state is being maintained (checking operation of O2 to O8 plus assessing changes in environment, legislation, operating procedures, personnel) Appendix O2 – Service Level Agreements Procedure for defining support requirements and agreeing support provisions between user and supplier (including control of fault reporting, workarounds / patches / upgrades, spares / consumables, routine calibration, support for software tools / hardware / infrastructure etc) Appendix O3 – Automated System Security Guideline for ensuring control, integrity, availability and confidentiality of data. Appendix O4 – Operational Change Control Guideline for review, risk assessment, authorization, documentation and re-test of changes. Allows exclusion of like-for-like replacement and emergency repairs (though emergency repairs must undergo the same review and control ‘after the event’). ONGOING OPERATION Change Control Service Level Agreement Periodic Review Performance Monitoring System Security Record Retention Backup and Recovery Business Continuity Planning RETIREMENT Retirement KEY: User Responsibility Joint Responsibility Supplier Responsibility

  19. GAMP Hardware and Software Categories • Risk of failure increases with the progression from standard to bespoke. • Many systems are built up multiple components of various categories. • Validation strategy needs to reflect this in order to ensure that effort is correctly focused.

  20. PROCESS CONTROL SYSTEM EXAMPLES Instrument operating system is usually not separable from firmware – see category 2 Most SCADA or DCS workstation software runs on one of the Microsoft Windows ® operating systems GAMP Software Categories (1) CATEGORY 1 – Operating Systems VALIDATION APPROACH - Record version (include service pack). The Operating System will be challenged indirectly by the functional testing of the application.

  21. GAMP Software Categories (2) • CATEGORY 2 – Firmware • VALIDATION APPROACH • For non-configurable firmware record version. Calibrate instruments as necessary. Verify operation against user requirements. • For configurable firmware record version and configuration. Calibrate instruments as necessary and verify operation against user requirements. • Manage custom (bespoke) firmware as Category 5 software PROCESS CONTROL SYSTEM EXAMPLES Instrument firmware including set-up parameters. 3-Term Controllers, Recorders, etc

  22. PROCESS CONTROL SYSTEM EXAMPLES Provided that ‘off the shelf’ solutions are purchased rather than creating bespoke toolkits: Historical data viewers Statistical analysis packages Configuration management tools Application development tools Diagnostic tools GAMP Software Categories (3) • CATEGORY 3 – Standard Software Packages • VALIDATION APPROACH • Record version (and configuration of environment) and verify operation against user requirements. • Consider auditing the supplier for critical and complex applications.

  23. PROCESS CONTROL SYSTEM EXAMPLES Control schemes configured from library blocks Simple mimics Recipes GAMP Software Categories (4) • CATEGORY 4 – Configurable Software Packages • VALIDATION APPROACH • Record version and configuration, and verify operation against user requirements. • Normally audit the supplier for critical and complex applications. • Manage any custom (bespoke) programming as Category 5.

  24. PROCESS CONTROL SYSTEM EXAMPLES Sequence Function Charts Custom reporting using SQL queries Complex mimics running scripts GAMP Software Categories (5) • CATEGORY 5 – Custom (Bespoke) Software • VALIDATION APPROACH • Audit supplier and validate complete system .

  25. GAMP Software Categories Spreadsheets / Tools Special Considerations for Spreadsheets Can fall into category 3, 4 or 5 depending on use. Examples: Category 3 – used purely to generate a paper document Category 4 – more complex application involving templates Category 5 – spreadsheet application using custom macros Application Development and Diagnostic Tools Can be bespoke or off-the-shelf Validation requirements depend on software category and on whether the tool directly supports the business process (eg application builder) or only supports the development or management of applications (eg configuration management tool)

  26. GAMP Hardware Categories • CATEGORY 1 – Standard Components • VALIDATION APPROACH • Record model, version, serial number. Verify correct installation / connection. Apply change control. • CATEGORY 2 – Custom Built Components • VALIDATION APPROACH • As for standard components but also require a design specification and acceptance test. Supplier may be audited.

  27. The Eurotherm GAMP Offering AIM – to understand how Eurotherm interprets the GAMP lifecycle and software / hardware categories GAMP?

  28. Example Architecture 1 – Control System Ethernet Eurotherm Suite Server / Viewer ALIN Visual supervisor Profibus 2500 I/O

  29. Example Categorisation 1 – Control System PC Windows NT HARDWARE SOFTWARE GAMP4 SOFTWARE CATEGORIESY PC 1 – Operating System Eurotherm Suite Eurotherm Suite Viewer Database, Security, Alarming, Mimics, Trending. 2 - Firmware 3 – Standard Software Package 4 - Configurable Software Package 5 - Custom Software T800 T800 Visual supervisor Continuous Control and mimics GAMP4 HARDWARE CATEGORIES Sequencing 1 – Standard Components 2 - Custom Built Components 2500 I/O 2500 2500

  30. Example Architecture 2 – Graphic Recorders Ethernet PC viewer running Bridge 5000 Data PC running Review 5180V 5180V

  31. Windows NT (inc ftp server) Windows NT Review Bridge 5000 Review configuration 5180V 5180V Config Config Example Categorisation 2 – Graphic Recorders PC Remote PC 5180V 5180V Recorder configurations shown as category 4 Also available treated as category 2 for simple configurations only (no user screens, no maths channels) Software Categorisation 1 – operating system 2 - parameterised firmware 3 – ‘off the shelf’ 4 - configured 5 - coded

  32. Project Deliverables Compared PLANNING AND DEFINITION Category 4 / 5 Visual Supervisor Category 2 Graphic Recorder QualityPlan Standard Functional Spec Functional Specification SPECIFICATION, DESIGN, CONSTRUCTION Standard IQSpec IQ Spec Module FS +TS Hardware DS + TS OQ Spec Produce Hardware Produce Hardware Produce Configuration Produce Software SW Module Test HardwareTest DEVELOPMENT TESTING AND SYSTEM BUILD Internal Test Integrated Test DESIGN REVIEW & ACCEPTANCE Factory Acceptance InstallationQualification COMMISSIONING AND QUALIFICATION InstallationQualification COMPLETION OF QUALIFICATION AND ONGOING OPERATION (TO CUSTOMER PROCEDURES)

  33. End Slide

More Related