GAMP 5 and GAMP 5 2nd Edition: What are the main differences?

GAMP 5 (Good Automated Manufacturing Practice) is a risk-based approach for the implementation, operation, and validation of GxP Computer Systems in regulated industries – including the Life Sciences.

Recent technological advances have forced many organizations to rethink their business models once they realized a noticeable number of activities and documentation no longer added value to their company.

That is why GAMP 5 2nd Edition, published in July 2022, is the most significant update in over 14 years. Its objective was to update guidance to contemporary practices and specifically eliminate burdensome approaches.

The 2008 legacy GAMP 5 focused too much on compliance and on avoiding inspection findings rather than advancing products and processes through new technologies. With the 2nd Edition, a novel critical thinking methodology has emerged as a cornerstone of the guideline. Now, the approach is more oriented toward patient safety, product quality, and data integrity.

 

Structure of the New GAMP 5 2nd Edition

 

GAMP 5 2nd Edition consists of a main body text and several supporting appendices. The main body is the framework that provides guiding principles and a lifecycle framework applicable to GxP regulated computerized systems. The appendices support the main body and provide specific practical guidance on various topics. Some details have been updated in this new edition, while others are new; three of them have been retired and incorporated in other appendices.

The following is a summary of the main changes in the GAMP structure:

 

Contents
1. Introduction	Updated
2. Key Concepts	No Change
3. Lifecycle Approach	No Change
4. Lifecycle Phases	No Change
5. Quality Risk Management	No Change
6. Regulated Company Activities	No Change
7. Supplier Activities	No Change
8. Efficiency Improvements	No Change
Management Appendices
M1 - Validation Planning	No Change
M2 - Supplier Assessment	No Change
M3 - Science-Based Quality Risk Management	No Change
M4 - Categories of Software and Hardware	No Change
M5 - Design Review and Traceability	No Change
M6 - Supplier Quality Planning	No Change
M7 - Validation Reporting	No Change
M8 - Project Change and Configuration Management	No Change
M9 - Documentation and Information Management	No Change
M10 - System Retirement	No Change
M11 - IT Infrastructure	New
M12 - Critical Thinking	New
Development Appendices
D1 - Specifying Requirements	Significant Updates
D2 - (Retired)	Incorporated into Appendix D1
D3 - Configuration and Design	No Change
D4 - Management, Development, and Review of Software	No Change
D5 - Testing of Computerized Systems	Significant Updates
D6 - System Descriptions	No Change
D7 - Data Migration	No Change
D8 - Agile Software Development	New
D9 - Software Tools	New
D10 - Distributed Ledger Systems (Blockchain)	New
D11 - Artificial Intelligence (AI) and Machine Learning (ML)	New
Operation Appendices
O - Introduction to Operation Appendices	No Change
O1 - Handover	No Change
O2 - Establishing and Managing Support Services	No Change
O3 - System Monitoring	No Change
O4 - Incident Management and Problem Management	No Change
O5 - Corrective and Preventive Action	No Change
O6 - Operational Change and Configuration Management	No Change
O7 - (Retired)	Incorporated into Appendix O6
O8 - Periodic Review	No Change
O9 - Backup and Restore	No Change
O10 - Business Continuity Management	No Change
O11 - Security Management	No Change
O12 - System Administration	No Change
O13 - Archiving and Retrieval	No Change
Special Interest Appendices
S1 - Alignment with ASTM E2500	No Change
S2 - Electronic Production Records	Significant Updates
S3 - End User Applications Including Spreadsheets	No Change
S4 - Patch and Update Management	No Change
S5 - (Retired)	Incorporated into Appendix M11
S6 - Organizational Change	No Change
General Appendices
G1 - References	No Change
G2 - Glossary	No Change

 

 

Particularly, the following key topics have been refined and strengthened in the updated edition:

• Focus on patient safety, data integrity, and product quality
• Process and product understanding
• Lifecycle approach within a quality management system (QMS)
• Scalable lifecycle activities
• Science-based quality risk management
• Leveraging supplier involvement

Others have been updated to include current technology (artificial intelligence (AI), machine learning (ML), and blockchain).

The key concepts of the general framework have been maintained. Some appendices have been updated and other new appendices have appeared for the first time in GAMP 5 history.

Overall, these changes were made after considering novel technology, new processes, new topics, and technical topics that required an update in management, development, and operations guidelines.

 

Overview of GAMP 5 2nd Edition

GAMP 5 2nd Edition is based on one key goal: to “protect patient safety, product quality, and data integrity by facilitating and encouraging the achievement of [computerized] systems that are effective, reliable, and of high quality.”

The main issues highlighted in GAMP 5 2nd edition surround innovation, critical thinking, agile methodologies, and IT service management. The guidance shows a clear evolution from Computer Systems Validation (CSV) to Computer Software Assurance (CSA).

 

Linear Approach vs. Agile Approach

The 1st edition of GAMP 5 published in 2008 suggested a linear approach for the development and validation of software. That made sense in the early 2000s, when software was still static and releases were less frequent: You bought an application, you installed it on your system, and validation (via CSV) was completed in a one-and-done process. Back then, the so-called V Model was the most used approach to develop and validate a computerized system during its lifecycle in GxP environments. The V model is a waterfall model, where the development and testing activities go together linearly. It comprises the following sequential steps:

• • Analyze
  • Plan
  • Design
  • Build
  • Test
  • Fix
  • Test
  • Deploy

 

 

Today, GAMP 5 2nd Edition suggests an agile approach, which is non-linear. It represents a cultural and mindset shift. Current modern software development uses an iterative, incremental and exploratory approach. This approach is more of a cyclical process. The waterfall V model is not necessarily the most convenient approach anymore.

 

 

The left side of the V Model includes the verification activities (URS, Functional Specifications, Design) and the right side includes the validation activities (Unit Testing, Integration Testing, System and Acceptance Testing). These two sides are connected through the Development Stage.

The Agile Model requires a discovery mindset, rather than a certainty mindset. The discovery mindset enables us to manage learning and adaptation throughout the development lifecycle in a controlled way:

 

As most of the applications we use today in quality management systems are cloud enabled, the reality is that software is no longer static like it was back in 2008. Improvements are constantly being applied to your QMS and other software.

The agile model is useful because it is iterative, incremental, and exploratory. Additionally, the use of risk-based methodology helps with ensuring full compliance with this new methodology.

 

Paradigm Change:
From Documents to Tools and Systems

We are moving away from traditional paper documents and toward keeping records and information in tools and systems.

In the early 1990s, the GAMP guide was mainly used to control suppliers of manufacturing production equipment to the pharmaceutical industry. Thus, the V model was used in the first four versions of the GAMP guide from 1994 to 2008. This V model worked very well for manufacturing equipment and equipment with computer control elements with simple configuration. But there are better-suited alternatives now.

With the recognition of agile methodology in GAMP 2nd Edition as a non-linear approach for software development and validation, legacy validation documents from GAMP 1st Edition, such as installation (IQ), operation (OQ), and performance qualification (PQ) documents, are no longer relevant.

 

Critical Thinking

A new appendix (M12) has been included in GAMP 5 2nd Edition. Critical thinking is the most interesting addition to this new version. It is a basic pillar of the guideline. Critical thinking is now aligned with the new FDA guidance “Computer Software Assurance for Production and Quality System Software” that has been published in September 2022.

The appendix encourages the application of critical, patient-centered, risk-based thinking to software assurance.

 

Infrastructure

A new appendix (M11) has been included in GAMP 5 2nd Edition. Modern management approaches, using automation tools appear in the guideline:

• • Artificial Intelligence
  • Cloud technology
  • Blockchain

The appendix also clarifies new expectations around electronic records, signatures, and audit trails.

 

ITIL Approach to Software Development (IT Infrastructure Library)

All operation appendices have been brushed up and updated to reflect an IT QMS item approach, leading to more clarity in change management vs. problem management vs. incident management.

 

Main Changes in GAMP 2nd Edition

 

Changes in the Introduction

Specific emphasis is given in this new version to apply critical thinking and risk-based approaches as a cornerstone to safeguard patient safety, product quality, and data integrity in the use of GxP computerized systems. Now, compliance is longer the only focus of the guideline.

The guidance is now aligned with ISO 14971 for medical devices – application of risk management to medical devices and agile approach for development and validation.

The introduction covers the justification for updating most of the technical content of the guideline, not the main framework, to include the importance of IT providers, agile methodology, the use of software tools to be used throughout the lifecycle, the inclusion of artificial intelligence and machine learning (AI/ML), blockchain, cloud computing, and Open-Source Software (OSS).

The general framework, key concepts, system lifecycle, specification, verification approach, and Quality Risk Management (QRM) process remains unchanged.

 

M11 - IT Infrastructure

This is an appendix that was originally identified as Appendix S5 in the first edition. This appendix applies current risk-based thinking on good practices for managing the infrastructure that resides within a regulated company’s own facilities as well as to external suppliers based on the cloud (IaaS, PaaS, and SaaS).

Infrastructure must be managed to a controlled state. Both confirmation of components’ fitness for purpose and management to a controlled state are likely to involve automated processes.

The guideline suggests QA to have a reduced oversight in some minor changes, by having an agreement between IT and QA with a standard change list without the need of a formal change control, for example, when there is a need to perform a change with low-risk.

 

M12 - Critical Thinking

This is a new appendix. Critical thinking is in favor of applying sufficient thought to ensure the approach taken is customized and proportionate to the needs of different systems.

A pragmatic approach is promoted that is against over-compliance and against activities that are non-value-added compliant. It is also against the use of rigid tables, predefined templates, and tick-in-the-box methods that could inhibit innovation and the adoption of new technologies.

A good practice is to map and understand processes. Risks should be found to ensure that the computerized system is fit for purpose with the best implementation strategy.

Critical thinking can be applied in all activities related to validation (preparation, execution, and review) to consider which activities add value. Only added-value activities should be considered for remedial actions. Here, more really is less.

 

D1 - Specifying Requirements

There is a significant update to this appendix. The legacy GAMP 5 1st Edition contained separate appendices for User Requirement Specification (URS) and FRS (Functional Requirements Specifications). Now they are combined into this appendix D1.

The main revision is about the use of Agile development methods and the use of tools and automation in the capture and definition of requirements. Requirements specifications can now be maintained in an appropriate management tool or in a document, depending on your methodology (agile V model).

All requirements are to be categorized and prioritized based on criticality to patient safety, product quality, and data integrity.

 

D5 - Testing of Computerized Systems

There is a significant update to this appendix, mainly related to the concept of computer software assurance (CSA). The appendix covers the testing of GxP computerized systems, offering information on the types of testing approaches that can be used for optimal assurance that the system is fit for its intended use. Testing should be limited in the use of GxP cases based on risk assessment.

Now, more testing is more important than more documentation. An example of this is the adoption of an exception-reporting approach to recording results. This means that if the system is working as intended, a simple “Pass” recording is enough. There is no need to capture excessive screenshots as evidence in most of the tests. Only those tests that are critical may require additional screenshots as evidence. It is better to focus on unexpected issues to find the root cause and apply the proper corrective action. This is more valuable.

The guidance mentions that looking for minor errors in documentation gives little value and poses a low risk to patient safety, product quality, and data integrity. Hence, it is better to focus on other issues.

Regarding validation packages from suppliers, they can be effectively leveraged to satisfy the GxP verification requirements to avoid duplication. This acts as an additional layer of assurance. There is no reason not to use the validation package from the supplier: The more you can leverage the better.

Regarding the person that executes the testing, GAMP 5 requires identifying who is performing the tests, as the quality of testing is significantly impacted by the knowledge and skill of the tester. At the same time, GAMP 5 states it is unnecessary to use test witnessing or to require the tester to initial every single test step to affirm they followed the instructions. A final signature at the end of the page is enough.

 

D8 - Agile Software Development

This is a new appendix. The focus is on how to use agile processes to deliver software for GxP applications without modifying the agile methodology according to GxP requirements, for example, by superimposing linear (V model) activities.

Some organizations are purchasing Software as a Service (SaaS) products from companies that are using agile software development, like the Jira tool. These companies are able to be agile to continually improve. They push updates while the regulated customer maintains the compliance state.

With agile, teams can deliver effective and useful software in a controlled way that is compliant with GxP regulations. It is a different mindset where discovery encourages acting, learning, and rapid continual improvement.

The guideline describes that the planning, specification, verification and reporting activities are not inherently linear. Agile is compatible with other incremental, iterative, and exploratory models and methods.

Software development using an agile approach discovers and iterates ongoing changes as opposed to waterfall software development, used in the legacy guideline GAMP 5 1st Edition.

In addition, GAMP 5 2nd Edition clearly states that 21 CFR Part 11 is not applicable to the approval process of Agile methodology, as the approval is not equivalent to a traditional handwritten, which is a legally binding signature required by a predicate regulation. In other words, only Part 11 records need a special level of scrutiny.

The approval of software lifecycle deliverables can also be achieved by many other means (e.g., status change, email, audit trails).

 

D9 - Software Tools

This is a new appendix that applies to softwares that are not components or applications in a GxP-regulated business process, like Jira. As they cannot directly impact GxP data/records, the predicate rules do not apply.

The guideline states that tools used in computerized systems lifecycle processes, IT processes, and IT infrastructure processes do not require computerized system validation. They can be managed by good IT practices. Instead, you can perform an IT risk assessment and procurement practice instead of formal validation.

 

D10 - Distributed Ledger Systems (Blockchain)

This is a new appendix. Currently, blockchain technology is not yet widely implemented in GxP environments. However, blockchain technology could be used for very specific applications, such as the recording and tracking process and product activities across the product lifecycle, from the purchase of raw material to the final consumer, giving high security and transparency. An application could be for the use of audit trails, and public or private networks.

 

D11 - Artificial Intelligence and Machine Learning

This is a new appendix. Artificial intelligence (AI) and machine learning (ML) are new technologies to automate many functions previously performed by humans. As long as you are able to define the boundaries of the AI and ML algorithm and the use case, the system can be validated. The use of key performance indicators acts as the technical specifications for the acceptability of the ML model.

 

S2 - Electronic Production Records

Due to the evolution of novel technologies, this appendix was updated significantly. There is more clarification on data audit trails and the frequency of data audit trail review according to predicate rules and also for non-cGMP data.

Risk-based methods are to be used to define which audit trails should be reviewed and at what frequency.

Regarding backup and recovery of electronic data, it is basic to define the recovery point objectives (RPO) that dictate the frequency of backups, and the recovery time objectives (RTO) that dictate the interval between system failure and recovery. This period of time is expected to be in line with the system risk assessment.

Which Appendices Have Been Retired?

 

Appendix D2
Functional Specifications

Appendix D2 Functional Specifications has been retired. The content has been incorporated into Appendix D1 Specifying Requirements.

 

Appendix O7
Repair Activity

Appendix O7 has been removed. Repairs are to be managed as standard changes, service requests, and/or system administration tasks. The requirements for repair activities are now defined in Appendix O6.

 

Appendix S5
Managing Quality within an Outsourced IS/IT Environment

Appendix S5 has been withdrawn. The revised content has been included in Appendix M11.

 

References

¹ ISPE. (2022). GAMP5, 2nd Edition, Section 1.1 Rational for GAMP5 Second Edition.

 

 

Know how to keep your processes and products GAMP5 compliant with Scilife Smart Quality Platform!