Mr.Rajendra.Sadare

Senior Software Engineer-Testing and Validation

Arisglobal Software Pvt.Ltd

Agenda

What is GAMP?TerminologiesValidation Life Cycle as per GAMP-4

guidelines.Risk Management.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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)

Risk Management Approach

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)

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

Low Impact Records

Planning documents

SOPs that govern validation of automated systems

Management information for validation or internal audits

Record Control Implementation

Procedural and technical controls for: Security Backup and restore Disaster recovery Audit trail Record Copying Record Retention

Backup and Restore

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

Disaster Recovery

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

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

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

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.

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

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.

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.

Getting it right…

“Validation is nothing more thanwell documented common sense”

But remember :“If it isn’t documented, it’s a rumour” !

Dr Ron Tetzlaff – Former FDA National Expert

Ken Chapman, 1985 – Chairman of Pharmaceutical Manufacturer’s Association Computer Validation Committee

Discussion

Thank you.