Introduction to GAMP4

1. Mr.Rajendra.Sadare
Senior Software Engineer-Testing
and Validation
© 2007 ArisGlobal

2. Agenda
 What is GAMP?
 Terminologies
 Validation Life Cycle as per GAMP-4 guidelines.
 Risk Management.

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. 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. 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. 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. 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. 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. 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. 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 are tested, and
clearly establishes the acceptance criteria for a given test.
 Validation Summary Report (VSR): 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 are tested,
and clearly establishes the acceptance criteria for a given test.

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.
 Decommissioning: Decommissioning is a controlled process used to safely retire a
facility that is no longer needed
 Supplier: A manufacturer who sells controlled products.
 End Users: Customer (The individual or group who will use the system for its
intended operational use when it is deployed in its environment.)

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. 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. Risk Management Approach

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. 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. Low Impact Records
 Planning documents
 SOPs that govern validation of automated systems
 Management information for validation or internal audits

18. Record Control Implementation
Procedural and technical controls for:
 Security
 Backup and restore
 Disaster recovery
 Audit trail
 Record Copying
 Record Retention

19. Backup and Restore
 Formal process
 Documented testing of process
 Frequency
 Backup verification
 Storage conditions, locations and remote storage
 Backup media refresh

20. Disaster Recovery
 Formal process
 Defined allowable time of outage
 Recovery mechanisms
 Documented testing of process
 Defined recovery point
 Ensuring error free operation

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. 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. 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.
 The unintended and undocumented
introduction of new versions of
firmware during maintenance must be
avoided through the application of
rigorous change control. The impact
of new versions on the validity of the
IQ documentation should be reviewed
and appropriate action taken.

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. 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
standard product. The audit
needs to consider the
development of the standard
product which may have followed
a prototyping methodology
without a customer being
involved.
 E.g.: All Arisglobal system.

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 existing
quality systems and a validation
plan should then be prepared to
document precisely what activities
are necessary, based on the
results of the audit and on the
complexity of the proposed
bespoke system.

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. Discussion

29. Thank you.