The Good Automated Manufacturing Practices (GAMP) were developed by the International Society for Pharmaceutical Engineering (ISPE) for pharmaceutical cleanrooms. The ISPE remains the governing body for GAMP. According to ISPE, GAMP is, “A system for producing quality equipment using the concept of prospective validation following a life cycle model. Specifically designed to aid suppliers and users in the pharmaceutical industry”.
In our experience, we see GAMP as more impactful beyond the pharmaceutical industry. GAMP works no matter the industry: they are excellent guidelines by which to run a cleanroom.
Since GAMP was released in 1991, there have been 5 revisions. The most recent was put out in 2008, which is what we refer to as GAMP5. The guidelines underwent major changes during this revision and now present an extremely comprehensive set of rules by which to run a traceable, above-board cleanroom.
GAMP5 goes over quality by design for Real-Time Monitoring Systems (RTMS). It covers patient safety and product quality while being driven by data integrity. It also revolves around gathering critical data through a RTMS and maintaining its integrity, starting with the correct implementation of a RTMS.
Because its focus is heavily on design, your cleanroom is better off from the start. GAMP5 has many design implementations that may seem tedious but save you time, money, and frustration in the long run. For instance, it focuses on using data to put the sensors in the right place from the start. If you install your system with sensors in the wrong place, you will end up with bad data and changing them in the future.
In our experience, we often see people make decisions to put sensors in certain places because it is convenient, seems logical, or feels right. But when they conduct a strategic risk assessment, they realize that it is not the best spot for the sensors.
Figure 1.1 GAMP V model
Figure 1.1 outlines the GAMP V model. To follow the flow, the process starts at the top left corner and flows to the top right. This outlines the implementation of a RTMS according to GAMP guidelines.
Figure 1.2 GAMP V Model Phase 1
The first portion of the V model covers the groundwork needed to implement a Real-Time Monitoring system. This is perhaps the most important step during the implementation of a RTMS. GAMP5 covers the Science-based Quality Risk Management analysis that should be done during this process. You should bring together a team of experts who understand your process and RTMS to help with this. This allows you to develop proper User Requirement Specification (URS) based on science and your quality risk management.
A strong URS is the starting point and ending point of a RTMS and any other computerized system you add. Here at Lighthouse, we have basic URS templates we offer customers so they can have a well-rounded starting point. It is fundamental to this process, as you will notice throughout the V model.
Once you develop your URS and supply it to your vendor, they will determine if the requirements are sufficient. It is important you consider the URS traceability matrix.
Figure 1.3 GAMP V Model Phase 2
Phase 2 of the V model comes next. At this point, you should have chosen a vendor and have an approved URS. During this phase, you develop the Functional Specification (FS) using the HW and SW specifications and the URS. You will use the FS to illustrate how the RTMS will operate, be designed, be configured, and what HW and SW will be used. You must identify all components of the RTMS, including the integration modes and communication (i.e. sensor accuracy, traceability, and adherence to cleanroom and calibration standards).
Figure 1.4 GAMP V Model Phase 3
During this phase, you will assemble your system based on your URS and FS. You will put together your sensors, system modules, digital output devices, serial to internet converters, software, database configurations, and any other configurations. This phase is your vendors’ responsibility with some interaction from you. Occasionally, you may change your mind during this process or decide to add more functionality, so we encourage you to regularly meet with your vendor for design reviews before the system is completely developed. This eliminates surprises.
We also recommend having all stakeholders and end-users involved. This is a large investment that is not taken lightly or done regularly, but many people are impacted. For instance, IT departments are heavily impacted but often not included in the process. They should be engaged from the start.