Validating a Facility Monitoring System
Non-traditional/practical approach
A company has a heating, ventilation and air conditioning (HVAC) system controlling and monitoring the environment in its facility, including non-good manufacturing practice (GMP) controlled areas. This HVAC solution consists of five different tailor-made systems, the oldest dating back to the late 1970s. The quality assurance (QA) department then decides that the system needs revalidating because the validation documentation is outdated or parts of the system are not validated. The company now faces a huge validation task.
If you recognize yourself in this scenario, you're not alone. This is a common situation often resulting in redesigning the entire system, which is time-consuming and costly. Is it possible to avoid an expensive and complicated validation of the entire HVAC system? Well let's review what the International Society for Pharmaceutical Engineering (ISPE) guidelines suggest on the topic:1
- "While it is good practice to monitor the performance of equipment such as fans and coils and control components, it is not a regulatory requirement."
- "It is possible to monitor, record, and/or alarm with portable or other instrumentation which is not a part of the HVAC control system."
- "Critical parameters should be monitored, either through the HVAC control system, a process control automation, or by manual methods..."
This means the environmental monitoring can be separated from the HVAC system, and it is, therefore, possible to monitor and validate only the GMP-critical parameters. Furthermore, through the FMS solution you can monitor the performance of the HVAC system. Figure 1 shows how such a system could be configured
Even if you separate the environmental monitoring from the HVAC system you will have to validate the FMS solution, but the validation effort will be significantly less. How can you avoid over-validating or ending up in a bottleneck of requirements and tests?
Systematic validation approach
As discussed in a previous issue of Pharmaceutical Technology Europe, the practical approach is to reuse and update existing system validation documentation, thereby practising the principles of the O-model.2 This is very convenient and practical — particularly regarding future system changes. Details regarding specific documents are explained here.
Validation plan. All validation activities must be well planned. The key elements of any validation projects should be documented in a validation plan (VPL). The VPL should be brief and clear including, but not be limited to, the following:
- Validation policy, including company and regulatory requirements.
- The organization structure of validation activities.
- Summary of FMS equipment subjected to the validation (overview of the system).
- Planning and scheduling, including prerequisites for approval of protocols.
- References to existing and future documents.
When more then one facility or FMS solution is being validated, it is appropriate to write a validation master plan (VMP) covering and controlling several VPLs addressing each specific system. Specifications. The most important document of any proposed system is the user requirement specification (URS). The URS is part of the required documentation to support the validation process, which is defined by FDA as: "Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes."3
The URS ensures that both the user and supplier understand what is required. The URS specifies what the system is supposed to do and the functional specification (FS) specifies how the system will do it. For example, one requirement in the URS could be that the system must generate three different alarm levels. The FS will then specify how this function is implemented. When the URS and FS are written you move on to the design of the system/design specification (DS). This specification should be a top-level document that clearly states what items are required, and how mechanical and software items are to be connected to fulfil the function specification requirements.
Implementation
FAT. The factory acceptance test (FAT) enables you to see how the system functions before delivering it to the site. The system is fully built using all system components and then tested to an approved set of protocols, which verifies that the system meets the acceptance criteria and system design.
After testing, the system is installed at site. If there are any test failures at this stage the supplier is obligated to fulfil the requirements specified in the URS. It is far simpler (and less expensive) to solve problems on the supplier's site than on the user's. When the FAT and the issues raised during the tests are resolved, a site acceptance test (SAT) can be performed.
IQ. The installation qualification (IQ) should include, but not be limited to, the following:4
- All items listed in the FS have been delivered and are of the correct type. IQ should secure that all support systems (user manuals, technical manuals, system diagrams etc.) are in place.
- All instruments have been calibrated and the calibration is still valid.
- All inputs/outputs of a data collection unit are operational and all switches, lights, transducers are functional.
Once it has been documented that the system has been supplied as detailed within the FS, operational qualification (OQ) can start.
OQ. This verifies that the system operates as stated within the URS and FS. There should be traceability from specifications to the OQ functionality test. OQ should include, but not be limited to, the following:4
- testing functions described in specifications
- testing the alarm limits of the calibrated sensors
- a specific part of the OQ should address 21 CFR Part 115
- backup and recovery procedures should be tested
- procedures regarding operator training and preventative maintenance requirements should be in place.
The OQ should permit a formal release of the system. It is important to ensure that once the system has been validated it is maintained as such.
Baseline. Baseline could be defined as a snapshot of the hardware and software configuration. Baseline would normally be taken at key milestones, such as prior to:
- formal testing
- IQ
- OQ
- release
- after change.
Why is baseline essential? Imagine a company having 250 sensors connected to an FMS solution. Baseline will control and monitor all components connected to the system. Furthermore the baseline document will specify all system parameters, sensor tag names and alarm levels. Changes to the system are usually processed with a change control procedure. Together with the change control, a baseline snapshot of the hardware and software configuration will provide an overview of the system configuration and components.
Maintaining the validated state
When a system is validated and in operation, measures should be taken to ensure that it remains in a validated state. This maintenance not only involves the integrity of the hardware and software, but also the documentation. The maintenance of a validated system includes many activities, which the user is responsible for. These could include:
- Standard operation procedures: should address alarm limits for each area and required corrective actions if any of the areas show a deviation from expected results. They should also detail how the system is backed up and the frequency of this.
- Training: all operators and QA staff using the system should attend training in system functionality. All training activities must be documented.
- Service agreements: all service agreements should include parts of the system that you are unable to address yourself (program updates or patches). In some cases it should include calibration of equipment (such as particle counters etc).
- Operational change control: all changes proposed during the operational phase should be subject to formal change control processes and be followed by baseline management.
- Instrument calibration: calibration routines must be implemented. Calibration and maintenance of instrumentation should be performed to approved procedures and standards.
Conclusion
Any pharmaceutical company facing a validation of its HVAC system should consider the possibility of separating the GMP-critical environmental monitoring sensors from the system and focusing the main validation effort on those sensors. Key words in any validation project are 'thorough specifications', 'test traceable to specification' and importantly 'baseline'. By following these principles you are well on your way to having a validated FMS.
References
1. Pharmaceutical Engineering Guide for New and Renovated Facilities, Volume 2 Oral Solid Dosage Forms Baseline Guide, ISPE (3109 W. Dr. Martin Luther King, Jr. Blvd., Suite 250, Tampa, FL 33607, USA, 1998).
2. C. Stage, Pharm. Technol. Eur. 17(8), 13–15 (2005).
3. General Principles of Software Validation; Final Guidance for Industry and FDA Staff (1987) www.fda.gov/cdrh/comp/guidance/938.html
4. Final Version of Annex 15 to the EU Guide to Good Manufacturing Practice pharmacos.eudra.org/F2/eudralex/vol-4/pdfs-en/v4an15.pdf
5. Title 21 Code of Federal Regulations (21 CFR Part 11) Electronic Records; Electronic Signatures www.fda.gov/ora/compliance_ref/part11
1 comment:
Software validation is a part of the design validation for a finished device, but is not separately defined in the Quality System regulation.more information
Post a Comment