Computer system validation ? increasing supplier value

All sectors of manufacturing are under continual pressure to bring new products to market quicker, stealing a march on the competition and maintaining their revenue stream.

Manufacturing industries are also under pressure to reduce the cost of design, production and distribution processes to increase margins and maximize return on investment (ROI). Pharmaceutical manufacturing is no different; competition is fierce, and investors in drug development and manufacturing companies are looking for a healthy return on their money.

However, whereas most manufacturing organizations have seen health and safety regulations tighten over recent years, pharmaceutical manufacturers are also under pressure from the regulatory authorities in the regions where they wish to market their products. The Medicines and Healthcare products Regulatory Agency (MHRA) in the UK and FDA in the US, for example, regulate and monitor pharmaceutical manufacturers from the process plant design stage through to the day-to-day production of active pharmaceutical ingredients (APIs) and finished products. Whereas being first to market is usually a key objective for manufacturing organizations to maximize product returns, pharmaceutical manufacturers have the added pressure of patent lifetimes. If most of the patent duration is used to perform clinical trials and build a manufacturing plant, there is a reduced protection time in which to recoup drug development costs.

These various pressures work against each other as shown in Figure 1. Complying with health and safety, and regulatory requirements inevitably increases costs, whereas shareholders want to see expenditure reduced. Patent protection periods limit the time over which high margins can be obtained so reducing the time-to-market is paramount.

Figure 1

It is the nature of control systems for process plants that they become an activity on the critical path of the manufacturing plant development. To complete the configuration of a control system all details of the process, instrumentation and control devices must be finalized. Similarly, to finalise site tests and commission the system, all aspects of the plant, including the installation of the instruments and control devices, must be complete.

Consequently, the time pressures on the control and instrumentation engineer are very high, regardless of the industry. For the pharmaceutical industry, however, we have the additional requirement to conduct the initial stages of computer system validation (CSV) on the control system before performance qualification (PQ) of the whole process control system can be undertaken.

When it comes to the site activities associated with those initial stages of CSV, things are not as bad as they appear. Operating companies can significantly reduce the time taken to perform installation qualification (IQ) and operational qualification (OQ) activities, enabling them to both reduce cost and get into production earlier, by capitalizing on the work performed by their control system supplier. Definitions of PQ, IQ and OQ are provided in Table 1.

Table 1

The principles discussed in the rest of this article could be applied to any packaged system, whether it includes controls or not. Therefore, the installation of, for example, a clean-in-place skid or a vacuum package that undergo functional acceptance tests in the factory before delivery could also gain from the proposition that follows.

Obtaining 'buy-in'

Our objective is to minimize site activities associated with validation by reducing IQ tasks wherever possible and only performing OQ activities where they are dependent upon the site environment; for example, where the control system interfaces to another piece of equipment that could not be installed or simulated within the supplier's works.

A prerequisite for this approach to be effective is to involve your site validation staff from the start.

Remember that you are required to produce documented evidence that the computer system has been installed as specified and that the functionality provided by the system meets the stated requirements. Your validation staff must feel comfortable that this documented evidence will be produced and that it will withstand an inspection from one or more of the pharmaceutical regulators. Whether validation activities are performed by your control and instrument engineers, as occurs in at least one major pharmaceutical production plant, or entirely by a validation department, it is necessary to obtain buy-in from those who are responsible for validation.

They must also be involved in the entire process, if only as an approval signatory, so that they can be assured that the results will meet the intended aim. It is also necessary to consider the effects on the individual. After all, this proposal removes work from the validation department, a proposition that may require some 'selling' on the grounds of overall company benefits.

It may not only be the validation department staff who need to be convinced that a different approach can meet corporate goals as well as saving time and money. In 2000, I attended the International Society for Pharmaceutical Engineering (ISPE) Annual Meeting in San Diego (CA, USA). One of the sessions, presented jointly by a US operating company and one of its suppliers promoted the use of factory acceptance tests (FATs) as part of the supply of packaged systems.¹

It seemed strange to me that there should be any form of debate about whether or not FATs should be performed. Over a period of 25 years as a supplier of control systems within the European market, FATs had always been an obligatory part of any contract. Additionally, the presentation made no reference to any form of validation activity. When I questioned this, the operating company presenter said that they would "never involve a supplier in validation".

It was clear that the supply of a packaged system was seen as a completely separate activity to the validation of that system; perhaps because purchasing and validation had always been two separate areas of responsibility. To add value to the supplier's scope it is, therefore,, necessary to also involve your purchasing department.

When you consider what is tested as part of an FAT you soon realize that some of the tests that would be performed for IQ and most of the tests that form part of OQ will have already been completed and witnessed.

For example, the installation of equipment within cabinets and the installation of software packages within the control system will all be verified as meeting the project specification. Similarly, functionality associated with instrument and actuator interfaces, operator interfaces, equipment control and recipe actions will also be tested against specifications.

If we can ensure that these test records can be used as part of the documented evidence then these tests or their equivalent will not need to be performed on site, thereby saving significant time and money.

Those parts of the system that cannot be tested in the factory will be tested during site acceptance tests (SATs), which provide another opportunity to collect documented evidence. Similarly, where evidence of the functionality of a complete instrument loop is required, the information can be documented during commissioning activities.

Involving the supplier

Any supplier who has an accredited quality control system will have the basic controls in place during project execution. However, the scope of supply needs to be explicitly extended to include some basic training of supplier project staff and the production of suitable records. The training to be given to supplier staff must cover an overview of validation, including the objectives of IQ, OQ and PQ, and how to generate specifications and records.

Using the GAMP Guide as the basis of the training is a good idea because it describes the relationship between the user requirements specification (URS), functional and design specifications (FDS), system test specification (STS) and the need to trace requirements from URS, through the FDS to the STS.² The arrows in Figure 2 illustrate the links that need to be recorded in the requirements trace matrix (RTM). It is beneficial for the supplier to generate the RTM, as many of the URS requirements will be covered by statements in the supplier's standard product specifications and manuals, and the supplier is in the best position to identify where these statements can be found.

Also noted in Figure 2 is the situation regarding requirements that are satisfied within product specifications. If the required functionality is provided in a commercial-off-the-shelf (COTS) product then this functionality has been tested by repeated use across many installations and so does not need to be tested as part of the system tests. Only where the supplier project team has configured standard functions do you need to test that the configuration is correct.

Figure 2

As a purchaser, however, you cannot absolve yourself of responsibility during the requirements trace process. First, the URS should be structured so it helps produce a trace matrix by

• limiting each clause to a single requirement

• giving a unique number to each clause

• indicating whether the clause is for information or is a requirement to be satisfied under the contract.

Second, you need to be satisfied that the references in the matrix do actually relate to each of the stated requirements. Including the trace matrix within the supplier's scope also encourages discussion on each of the clauses in the URS and anything that promotes communication between purchaser and supplier is a good thing.

Regarding supplier training, you must ensure that the test records are going to meet the needs of documented evidence. This guidance should include:

• The generation of test cases for each major section of the FDS, with sign-off points for each individual function, rather than signing off whole sections or pages.

• Using initials and date to sign-off tests rather than simply using tick marks. This also requires a separate list of names, responsibilities, signatures and initials.

• The use of black or blue ball-point pen rather than red (which may not photocopy) or pencil.

• The deletion of text by a single line strike-through, so that the original text is still legible, with the addition of initials and date.

• The command to never use liquid paper to alter a document.

Because the FATs will be witnessed by your own staff, they can help ensure the propriety of all test records. They will also be signatories to the tests, therefore, you will have evidence of who performed the tests and who witnessed not only their correct execution, but also that the desired result was obtained.

Case study

The supply of an automation system for an API manufacturing plant can help illustrate the concepts discussed above. In this case, an existing pharmaceutical manufacturing plant was modified to produce a new product, while still retaining the capability to make the product for which it was originally designed.

Because the existing control system could not be further expanded, input/output modules for new parts of the plant, and new controllers and operator interface were added to the existing field interface equipment. Product was made for stock so as to maintain supplies during the plant shutdown.

The URS, produced by the purchaser, was structured to aid traceability. A small extract from the URS is shown in Table 2, where numbered clauses can be seen along with a distinction between information and requirement clauses.

Table 2

As this was a batch production plant, the functional specification was structured in line with the S88 model for batch automation.³ In this way, the specifications related directly to the configured elements in the system. The functional specification was supported by design specifications and project standards, where the latter defined the design and implementation principles that would be used on the project. Together, the functional and design specifications were sufficient to configure the system and, perhaps more importantly, provide the documents against which the system could be tested.

Figure 3

The structure of the functional specification is shown in Figure 3. Each document had its own number and revision history so that some parts of the specification could be reviewed and approved before other parts were complete. Basing the structure on the control levels defined within the S88 model results in the minimum of interaction between the documents, allowing parallel document development to be practical.

Also, everything about a particular level was defined in the one document. For example, the human interface aspects of control modules are defined along with other aspects of basic controls in the basic control definition document. The human interface definition covered the generic aspects of the operator interface, together with alarm management and security access. An extract from the basic control definition document is shown in Figure 4, where a motor symbol is defined.

Figure 4

The traceability of requirements illustrated in Figure 2 includes the test specification. The requirements' trace process was made easier by generating a test case for each major section of the functional and design specifications so that there was a one-to-one correspondence between the FDS and the test cases. An extract from a test case document is shown in Table 3, where separate sign-off boxes are provided for internal tests and FATs. Where a particular test is not relevant to a group of tests then that box is shaded grey.

Table 3

Reaping the benefits

Our approach has been to make use of the work normally performed by the supplier to reduce the work that would otherwise be done on site. By simply ensuring that all test records are kept in a form that provides documented evidence that the system satisfies the requirements within the URS, we have added very little work for the supplier and opened up the opportunity for significant savings during the validation process. On one control system for an API manufacturing plant it was estimated that 11 weeks were removed from the site activities as a result of adopting this approach.

The validation master plan (VMP), IQ, OQ and PQ protocols still need to be produced, but parts of the IQ protocol and most of the OQ protocol can now be little more than lists that reference the test records from the FAT and SAT. It is often said that software does not break, it is already broken! The corollary to this is that the functionality provided by the software will not change when the system is installed on site unless the environment in which the software application is running changes; a simple justification for not repeating the tests.

The approach described in this article has been used on a number of pharmaceutical control system projects. Most of the purchasers have embraced the concept, including their validation staff, from the start. One major operating company actually provides document templates to their supplier so that all the documentation fits seamlessly into their document system. However, some have not had the courage to change their existing practice and so have missed the opportunity to reduce costs and get their products to market earlier.

References

1. S. Haisman and P. So, "Factory Acceptance Testing", Proceedings of the ISPE 2000 Annual Meeting, San Diego, CA, USA (2000).

2. ISPE Gamp 4, GAMP Guide for Validation of Automated Systems, ISPE (Tampa, FL, USA, 2001).

3. ISA ANSI/ISA-S88.01, Batch Control, Part 1: Models and Terminology (Research Triangle Park, NC, USA,1995).

Dr David James is principal engineer at Invensys Systems (UK) Ltd, UK.