Gamp Riskbased Approch To Validation


Published on

Introduction to GAMP4

1 Comment
  • how to download
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Gamp Riskbased Approch To Validation

  1. 1. Mr.Rajendra.Sadare Senior Software Engineer- Testing and Validation Arisglobal Software Pvt.Ltd
  2. 2. Agenda  What is GAMP?  Terminologies  Validation Life Cycle as per GAMP-4 guidelines.  Risk Management.
  3. 3. GAMP History  Therac-25 Incident: the software for a large radiotherapy device was poorly designed and tested In use, several interconnected problems lead to several devices giving doses of radiation several thousands of times higher than intended, which resulted in the death of three patients and several more being permanently injured.  In 1987 the Food and Drug Administration published a document entitled ‘FDA Guidelines on General Principles of Process Validation (See Title 21 Code of Federal Regulations (CFR) Part 820, and 61 Federal Register (FR) 52602, respectively)’.  The Good Automated Manufacturing Practice (GAMP) Forum was founded in 1991 by pharmaceutical industry professionals in the United Kingdom to address the industry's need to improve comprehension and evolving expectations of regulatory agencies in Europe. The organization also sought to promote understanding of how computer systems validation should be conducted in the pharmaceutical industry.  In 1994, GAMP partnered with the International Society for Pharmaceutical Engineering (ISPE) to publish the first GAMP guidelines. GAMP quickly became influential throughout Europe as the quality of its work was recognized internationally. Over time, GAMP has become the acknowledged expert body for addressing issues of computer system validation.
  4. 4. ISPE History  GAMP is a technical sub-committee, known as a COP (Community Of Practice) of the International Society for Pharmaceutical Engineering (ISPE).  ISPE, the International Society for Pharmaceutical Engineering, is the world's largest not-for-profit association dedicated to educating and advancing pharmaceutical manufacturing professionals and their industry. Founded in 1980, today ISPE serves 25,000 members in 90 countries.
  5. 5. Why Validation???  Software validation is a requirement of the Quality System regulation, which was published in the Federal Register on October 7, 1996 and took effect on June 1, 1997. (See Title 21 Code of Federal Regulations (CFR) Part 820, and 61 Federal Register (FR) 52602, respectively.)
  6. 6. What is Validation?  Validation (FDA Definition) : Establishing documented evidence that provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.  Validation (CDRH Definition) : An activity of confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.
  7. 7. Terms used in validation  Prospective Validation: A process conducted before new items are released to make sure the characteristics of the interests which are functional properly and which meet the safety standards.  Retrospective Validation: A process for items that are already in use and distribution or production. The validation is performed against the written specifications or predetermined expectations, based upon their historical data/evidences that are documented/recorded. If any critical data is missing, then the work can not be processed or can only be completed partially.  GxP: A general term for Good Practice quality guidelines and regulations, used in many fields, including the pharmaceutical and food industries. The titles of these good practice guidelines usually begin with "Good" and end in "Practice", with the specific practice descriptor in between. GxP represents the abbreviations of these titles, where x (a common symbol for a variable) represents the specific descriptor.  Change Request (CR): A formally submitted artifact that is used to track all stakeholder requests (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle. All change history will be maintained with the Change Request, including all state changes along with dates and reasons for the change. This information will be available for any repeat reviews and for final closing.
  8. 8. Terms used in validation (Cont..)  Release Notes (RN): The release notes typically describe new capabilities, known problems, and platform requirements necessary for proper product operation.  Validation Plan (VP): Document determining the validation activates along with approximate timings and responsibilities.  User Requirement Specification (URD/URS/SRS): The user requirements specification will be used as the basis for the development of the system acceptance test scripts / performance qualification test scripts  Functional Requirement Specification (FRD/FRS): A document that describes in detail the characteristics of the product with regard to its intended features. This document is the out come after one or more reviews by the stakeholders on the project at hand after having negotiated a cost-effective way to achieve the requirements the software needs to fulfill.
  9. 9. Terms used in validation (Cont..)  Design Specification (DRD/DS/DDD/DDS): A System Design Specification is created to define how the proposed system will fulfill the GXP Computerized System's requirements.  Qualification: The process of determining whether a system or component is suitable for operational use.  Installation Qualification (IQ): It is a document to verify that all the components of a system installed as per the documented specification.  Operational Qualification (OQ): It is a document to verify that system operates as per the documented specification.
  10. 10. Terms used in validation (Cont..)  Performance Qualification (PQ): The Performance Qualification (PQ) ensures that the total system performs as intended in the specified operating range. The total system includes all hardware and software components, associated equipment, people and procedures that make up the system. The execution process is conducted using company specific pre- defined dataset or actual live data.  Traceability Matrix (TM): It is very important that direct traceability is established between the specification and the test performed i.e. a cross reference from the test script back to the section in the appropriate specification where the function is defined. This traceability ensures that all parts of the software
  11. 11. Terms used in validation (Cont..)  Verification: is an activity to check are we building the product right?.  Validation: is an activity to check are we building the right product?  Testing: is the process to prove that the software works correctlyOne of the verification activity that forms the part of validation process  Commissioning: Obtaining and documenting evidence that equipment has been provided and installed in accordance with its specification and that it functions within predetermined limits when operated in accordance with operational instruction.
  12. 12. Risk Analysis.  Risk assessment is defined as a systematic activity that involves identifying hazard and estimating and evaluating risks.  Risk Management is the systematic application of policies, procedures and practices to the tasks of analyzing, evaluating and controlling risks
  13. 13. Types of Risk Analysis.  FMEA (Failure Mode and Effect Analysis)  FTA (Fault Tree Analysis)  HAZOP (Hazard and Operability Analysis)  HACCP (Hazard Analysis and Critical Control Point)
  14. 14. Risk Management Approach
  15. 15. High Impact E-Records  Clinical and non-clinical studies (patient safety)  Compliant files (product quality)  Master production and control records (release decisions)  Patient information letters (usage instructions)  Component, drug product container, labeling records (enable component traceability and product recall)  Batch records (production, product quality)
  16. 16. Medium Impact Records  Training/personnel records (indirect impact on product quality/patient safety)  Financial disclosure by clinical investigations (GxP regulation)  Inspection records  Review and approval reports  SOPs that govern batch release
  17. 17. Low Impact Records  Planning documents  SOPs that govern validation of automated systems  Management information for validation or internal audits
  18. 18. Record Control Implementation Procedural and technical controls for:  Security  Backup and restore  Disaster recovery  Audit trail  Record Copying  Record Retention
  19. 19. Backup and Restore  Formal process  Documented testing of process  Frequency  Backup verification  Storage conditions, locations and remote storage  Backup media refresh
  20. 20. Disaster Recovery  Formal process  Defined allowable time of outage  Recovery mechanisms  Documented testing of process  Defined recovery point  Ensuring error free operation
  21. 21. Audit Trail  Date/Time stamp  Time zone  Amount of information retained (who, what, when)  Access control and security of audit trail  Retention of audit trail  Backup and restore of audit trail
  22. 22. Category 1 (Operating System) validation as per GAMP4  Commercially available operating systems which are used in pharmaceutical operations are considered validated as part of any project in which the application software operating on such platforms are part of the validation process (i.e. the operating systems themselves are not currently subjected to specific validation other than as part of particular applications which run on them). Well known operating systems should be used.  For validation record keeping, record the name and version number in the hardware acceptance tests or equipment IQ.  New versions of operating systems should be reviewed prior to use and consideration given to the impact of new, amended or removed features on the application. This could lead to a formal re-testing of the application, particularly where a major upgrade of the operating system has occurred.  E.g.: Unix, Windows etc
  23. 23. Category 2 (Firmware) validation as per GAMP4.  Category 2 is Standard Instruments, Micro Controllers and Smart Instrumentation.  These are driven by non user programmable firmware.  Examples: Weigh scales, bar code scanners, 3 term controllers.  This type of software is configurable and the configuration should be recorded in the equipment IQ. 
  24. 24. Category 3 (Standard Software Package) validation as per GAMP4.  Category 3 is Standard Software Packages. These are called Canned or COTS (Commercial Off-The-Shelf) configurable packages.  To satisfy the validation, user requirement should be documented, reviewed and tested during OQ.  Supplier audit required for highly critical and complex objects, SOP should be established and training plans should be implimented.  E.g.: HPLC
  25. 25. Category 4 (Configurable Software Package) validation as per GAMP4.  Category 4 is Configurable Software Packages. These are called custom configurable package.  End user perform supplier audit to ensure that the level of quality and structural testing built into the
  26. 26. Category 5 (Configurable Software Package) validation as per GAMP4.  Category 5 is Custom built or bespoke systems.  Custom built or bespoke systems should be validated using the full system life cycle approach.  An audit of the supplier is required to examine their
  27. 27. Getting it right… “Validation is nothing more than well documented common sense” Ken Chapman, 1985 – Chairman of Pharmaceutical Manufacturer’s Association Computer Validation Committee But remember : “If it isn’t documented, it’s a rumour” ! Dr Ron Tetzlaff – Former FDA National Expert
  28. 28. Discussion
  29. 29. Thank you.