Simulation – heaven or hell?
Ken McWilliam, marketing manager of Pharmagraph, says simulation testing of cleanroom monitoring systems is viable if a partnership approach is adopted at the outset
Ken McWilliam, marketing manager of Pharmagraph, says simulation testing of cleanroom monitoring systems is viable if a partnership approach is adopted at the outset
Cleanroom monitoring carries with it a host of special requirements, such as particle counting and measurement of differential pressure used to facilitate containment, in addition to more traditional parameters like temperature and relative humidity.
Add to this regulatory requirements such as GMP compliance, adherence to FDA or MCA guidelines and validation issues and soon a seemingly simple system becomes a nightmare – the project fails to meet the deadline, runs over budget and valuable production time is lost.
However, it does not have to be this way – as the GAMP guides state, the key to implementing a successful cleanroom monitoring project is a partnership between the user and supplier.
Acquisition Systems has been supplying and installing cleanroom monitoring systems for more than 10 years and has formed a new division, Pharmagraph, to focus specifically on cleanroom monitoring systems. While it is accepted that every system is unique, a pattern has emerged over the years that enables common requirements to be met through a simple modular software implementation.
By distilling the specific requirements of the pharmaceutical industry it has been possible to produce a solution that balances ease of use with high functionality, but more importantly, one that can be readily validated and achieve compliance with 21 CFR part 11.
Pharmagraph has evolved an approach that splits the hardware and software elements of the monitoring system at a well defined interface and allows them to be exhaustively tested, in isolation if necessary, then brought together during qualification. This simple technique helps accommodate the tight timescales brought about by fitting in with a planned shutdown, perhaps for annual maintenance, and allows hardware such as particle counters and input/output subsystems to be tested and shipped to site independently of the software suite. Advanced simulation techniques permit the software subsystem to be substantially tested and documented evidence of its correct behaviour generated, with the hardware already shipped to site.
Real-time database
In Fig 1, the real-time database is central to success and offers a mechanism where inputs from particle counters and analogue measurement subsystems (typically temperature, pressure and relative humidity) are mapped into fixed locations within the database.
These locations, known as "points" have unique identifiers, descriptors, units and alarm limits. Live results are normally written to these points by the input device drivers, but a simulation driver can be easily substituted – no change is made to the database configuration during simulation, it is precisely the same database that will be loaded in the target system during qualification.
A great deal of debate has centred on the issue of simulation and its validity. It is of particular relevance where airborne particle counts are called for in the User Requirement Specification. In the case of more traditional parameters such as temperature or pressure, it is feasible to inject a calibrated signal into the transducer or subject it to an independently measured stimulus such as an isothermal bath.
However, when it comes to particle counts it is impractical or even physically impossible to inject a specific number of particles/m3 into each sampling port. The common practice of exercising inputs around alarm limits would not be viable in these circumstances. Through necessity, therefore, the counter input behaviour was the first to be tested by simulation and now this approach has been extended across the entire suite of input parameters.
Fig. 2 shows the functional split between hardware and software at the various stages of testing and qualification. During Factory Acceptance Testing of the software, a simulation driver is used in place of each input device driver and generates results at the same rate as the genuine device. The structure of the real-time database is such that the behaviour is the same irrespective of the source of the data. This allows the alarm behaviour for a class 100 room to be tested for compliance at 100 particles/ft3 and again at 101/ft3 for non-compliance, which would not be feasible with real particles being generated.
On-site qualification
The tests carried out during on-site qualification are simplified such that the physical location of particle counter sampling positions is positively and uniquely identified in the correct database location. The simulation-based testing is not used as a substitute for qualification, but is used to substantially support it. It still remains essential that all measured inputs can be shown to be located, calibrated, displayed, recorded and replayed correctly, according to agreed specifications. The GAMP 4 Guide for Validation of Automated Systems and its associated baseline guide publications allude to the elimination of unnecessary, time-consuming and therefore expensive repeat testing of elements that have demonstrably been tested by the supplier. Establishing an early partnership between user and supplier allows supplier's test documentation to be accepted as part of the user's qualification documentation – subject to QA approval and appropriate vendor audits.
One of the side effects of compliance with 21 CFR part 11 is that any changes made to the system configuration, even prior to handover, are recorded faithfully in the audit trail logs. The documented evidence called for by the FDA can readily be produced, for example, where a test originally failed, the cause was identified and the fault corrected and the test then re-executed successfully.
The audit trail, originally perceived by some as "Big Brother" can actually be used to greatly assist in the qualification and validation process.
