GAMP 5 Newsletter - Holistic approach to science-based risk management

• Top-down QM approaches along with better inclusion of Risk-based Analysis techniques;
• References to other GAMP Documents, e.g. GAMP Testing Practices, Part 11 approaches, Network Qualification, VPCS, ISPE Commissioning and Qualification Baseline® Guide, etc.
• Comprehensive revision of the GAMP appendices for better usage of templates;
• Complete integration of latest FDA Guidances (e.g. Medical Devices), PIC/S Guidance (e.g API), ICH Guidances Q9 (Quality Risk Management) / Q10 (Quality Management System), Process Analytical Technology (PAT).
• Holistic approach to science-based risk management in developing high-quality applications (includes new categorization)

GAMP 3.0 was devided into two parts - one for suppliers and one for pharmaceutical companies, to clearly define both areas of responsibilities for validation, implementation, and documentation. GAMP 4 in its next revision was addtionally seperating IT Systems and Process Control Systems. GAMP 4 is highly recognized as industry standard and guideline by the EMEA, FDA, PIC/s, and other oranisations and companies. The GAMP 4 document is available in different languages like English, German, and French as paper or electronic version.

The basic GAMP 5 lifecycle:

User Requirements Specification - URS

This document will specify your requirements (without over detailed explanations of your design solutions). Relevant Good Manufacturing Practices (GMP), Good Laboratory Practices (GLP) and other regulations or guidelines will be referred to. Your requirements will be prioritised into essential and desirable requirements.

The URS is the first step of a typical project is outlining the user's requirements - as far as a proper process mapping is existing . Process Requirements are transformed into system requirements. If the process is not well known and documented, it is useless to write any URS. Writing URS documents just to have the document, because validation department requires it, makes no sense at all. The URS is documented in GAMP4, Appendix D1.Each requirements should have a unique identification number, e.g. RQ1000.

Also called a Functional Requirements Specification (FRS) or even Functional Description (FD).

Functional Specification - FS

This document will respond to the URS. A "Requirements Traceability Matrix" or RTM should be included, if required. The FS will explain what the end system will do, what is to be provided and the design objectives for the system. Any limitations or URS exceptions should be described. The FS is the second step of a typical project and a direct response to the URS. The FRS is the principal document to define what the system will do and what functions are to be provided by the system.

The Functional Specfication should be written by the supplier. It is a clear system description and asures that all requirements are understood and covered by the solution. The detailed technical description should be written into the Design Specifications, see below.

Design Specification - DS (H-DS and S-DS)

This represents a family of documents - Hardware Design Specifications, Software Design Specifications and Software Module Design Specifications. The H-DS defines for example the electrical control system and ancillary systems including computers, I/O, PLCs, environment and electrical supplies. The S-DS is the software corollary to the H-DS. The S-DS covers databases, software modules, and other aspects of the software engineering involved in the project.

Software Module Design Specifications should be written by the project developer, as far as code is produced. Code Review should be executed during development and should be based on the QM System of the supplier. Traceability Matrix´s are often written to trace back to the FS and URS.

These are detailed design documents intended to outline the actual design of a system.

Design Review - DR

Sometimes called a Design Qualification (DQ). This is a check stage where the requirements are reviewed against the proposed design to verify that the system will perform as required. This step of the project provides for a documented check of the project to date (URS, FS, DS) to verify that the URS (and Validation Plan) track through correctly.

Categorisation

GAMP specifies areas of review including looking for dead code, modular programming, annotation and an appropriate tag-naming convention. GAMP recognises five levels of code - Level 5 ("bespoke") requiring the most attention.

GAMP4 categorises code according to the following:

• Category 1 - this is an area to categorise "Infrastructure Software". An evaluation of the O/S itself is not required. The version number of the O/S along with patch and hotfix information is recorded. If the version number is changed or patches are applied then this could lead to failure of applications running on the O/S. See teh GAMP Good Practice Guide: IT Infrastructure and Compliance Guide (or e.g. ITIL Standards)
• Category 2 - This Category is no longer used in GAMP 5
• Category 3 - this is "non-configured products" (e.g. COTS software)
• Category 4 - this is "configured" software such as SCADA, ERP, CDS, DCS, MES and LIMS.
• Category 5 - this is "custom applications" in the meaning of software cucstom designed and coded to suit the specific business process.

Supplier Audit Programmes

An effective Supplier Audit Programme (as required by GAMP for Category 5 software systems). An actual Supplier Audit can either be accomplished "by post" (i.e., remotely) or "in person". The scale of the project and the effectiveness of each type of audit must be considered prior to executing the programme. A Supplier Audit Programme includes questions pertaining to:

• Company information;
• Company organisation;
• Quality management programmes (QMS);
• Planning and product/project management;
• Correct use of specification documents (e.g., S-DS);
• Project implementation programmes (e.g., software coding standards and Software Configuration Management - SCM);
• Test programmes (e.g., QA testing of code);
• Completion and release programmes (i.e., kit released / hot fixes to customer);
• Support and maintenance programmes;
• Background support for QMS, SCM, security and other programmes.

It is expected that where a supplier does not meet expectations, a written follow-up is made along with subsequent checks to verify that the supplier has adequately addressed their deviations. Also, an annual re-audit is expected for suppliers such as System Integrators who supply services for many projects.

Find here consultancy services provided by comes compliance services.