Robert GlaserThe US Food and Drug Administration (FDA) imposes strict requirements on owners and operators of production facilities in regulated sectors. Manufacturers in these sectors, such as pharmaceutical and food & beverage companies, for example, are only permitted to produce goods in authorized facilities that are Good Manufacturing Practices (GMP) compliant. If a system has not been validated, it may not be used to produce products or bring them to market.
Validation is part of the quality risk management process, pursuant to the GMP, for the installation of technical systems. The legal responsibility to carry out a validation process, and the obligation to provide proof of compliance with all included steps, always lies with the manufacturer. The complexity involved in the validation process of a system places great demands on a company's resources, and, can have a substantial negative impact on the integrity of the produced goods if carried out incorrectly. While a company may have very precise knowledge of their requirements, it is the software provider, for example, who knows the system and its range of functions best. In order to carry out the qualification phase of the validation process of a software, the manufacturer requires an exact product description as well as a risk assessment of the resulting specifications for their production process. The qualification of a facility can be carried out by the manufacturer themselves or it can be carried out in cooperation with their suppliers. Suppliers—e.g. software providers—can use their expertise to help successfully support the manufacturer during the qualification process.
Guidelines and requirements in regulated sectors
The guidelines that need to be adhered to during the validation process of both production facilities and systems are stipulated by regulatory authorities. One such example is the Good Manufacturing Practice (GMP) guidelines imposed by the Food and Drug Administration (FDA). It is the company's responsibility, however, to record the requirement specifications with which the implementation of such guidelines will be achieved. How these steps are carried out—from the planning of the facility to its commissioning and maintenance—is governed by the GMP guidelines stipulated by regulatory authorities (e.g. the FDA). The same is true when it comes to documenting these processes. Any errors that may occur as a result of manual documentation need to be avoided. In this context, a data management system can help to drastically reduce the incidence of human error, and, at the same time, be used to manage all device and data documentation of a production facility that is in the process of being set up. The inclusion of a data management system in the User Requirement Specifications (URS) helps to facilitate the validation process from the very beginning. Data is regularly, reliably and consistently backed up; and documentation is available at all times in accordance with a Change Control Process. Hence the change history is also available at all times. This ensures the traceability of the process data from the draft stages, throughout implementation and on to the production phase, and is the only way to both completely ensure and demonstrate the integrity of the product.
URS – the basis of a successful validation process
The User Requirement Specification (URS) sets out the requirements that a system needs to fulfill. It also clearly sets out the specifications of that system and what is expected of it. The URS needs to include a precise description of the system in question. It also needs to express both the requirements of the manufacturer as well as those of the end-client. Clearly setting out all specific requirements regarding the product, facility, and processes lays the foundation for fulfilling the criteria stipulated in the URS. Experience and knowledge are more important than ever during the early phase of a project, as is the functionality and efficiency of the system in question. Without these things, oversights and mistakes can cause a ripple effect that impacts the entire realization of a project. Because every step of the system validation process (from the very beginning) depends on the quality of the URS, it is essential that all specifications set out in the URS be precise, consistent and realistic.
In order to be able to precisely formulate the requirements of a system, it is first necessary to clearly identify what is expected of the system in terms of its functionality and to define what its capabilities and limitations are. With this knowledge, it will be possible to set out—in the URS—a clear process description for the system, a general software and hardware specification, and a functional risk assessment (FRA) of the system. But if this knowledge is not there, staff members working for manufacturers in GMP regulated sectors will first have to spend time acquiring it before they are able to specify the requirements of the system in the URS and FRA. It is exactly at this point of the process that there is scope for improvement. By cooperating with the suppliers of all systems involved it is possible to greatly simplify and accelerate the first (and most important) step towards achieving successful validation – namely, the task of formulating the URS. This knowledge transfer has two benefits: it saves time and it improves the quality of the URS.
The specifications of the URS are used to assess any risks that the system may pose to the GMP environment. This assessment is referred to as the Functional Risk Assessment (FRA). During the process of developing the URS, the FRA is revised. Identified potential risks are first carefully evaluated; and where it is considered necessary action is taken in order to reduce them to a less critical level.
Once the first stage of validating a system has been concluded, the next stage is to prepare and carry out the Installation Qualification (IQ). This process is not always clearly delineated—neither in general nor in academic publications—from the Operational Qualification (OQ). It is therefore worth taking a closer look at what these two validation phases entail and the differences between them.
IQ and OQ
The IQ checks to see if the system environment and all relevant requirements for the operation of the system are present, suitable and documented. This includes the location of the system and its connection to the necessary infrastructure. When it comes to validating software, various questions are raised, such as, for example, whether the right network architecture is available. In addition, the capacity of the network also needs to be considered. For example, a network whose bandwidth is too small can severely impair the functions of different systems. If the location of the system in question is situated in a production environment, it will need to be checked in order to determine (1) if there is sufficient memory available and (2) whether the system might be impaired by other components of the same system.
While some manufacturers check the basic system requirements during the IQ phase, for others further test steps are necessary. These producers first need for the system to be correctly installed in order to be able to test the basic functions described in the URS successfully. These basic functions are validated using a series of test steps, which are based on the general functions described in the URS. The IQ is thus, for some customers, documented proof that a system is compliant with the requirements set out in the URS, and, for others, it is also a basic requirement that assures that the basic requirements for installing a system are fulfilled. The system is checked to make sure that the hardware and software requirements are fulfilled and to confirm that the installation package is available in full.
This different approach to viewing the scope of the IQ also brings the scope of the OQ into question. The OQ always concludes with testing the specific functions of a system. The system not only needs to be successfully installed at the designated site, it also needs to fulfill the specific requirements that are set out in the URS. Where the scope of the OQ begins is where opinions begin to differ. One viewpoint is the above viewpoint, which maintains that OQ begins with testing the basic functions of the system. The other viewpoint is that OQ begins with testing the specific functions set out in the URS.
Once the OQ has been successfully concluded, the facility is qualified and normal operations can commence. From this point onwards, a regular Performance Qualification will ensure that the facility continues to fulfill the additional requirements set out in the URS.
Example of the validation process for a data management system
In order to illustrate how the validation process of a software system could be carried out, we will take a look at using a data management system. The system can be used to document and create backups of data taken from, among others, PLCs, robots, frequency converters, conveyers, drives, and HMI terminals. It provides one reliable and consistent data backup strategy for rapid disaster recovery.
Companies working in regulated sectors, who manufacture in accordance with the GMP criteria set out by the FDA, not only need a backup and recovery strategy for their devices and software programs, but they also need to ensure that all production processes are regularly documented. In order for a data management system for automation to be permitted to operate in GMP regulated sectors, it not only needs to fulfill these requirements but must also be validated in accordance with the validation process displayed in the image below.
Figure 1: Validation process for GMP-regulated sectorsKey to the creation of a complete URS is the combination of the expertise of the operator—with respect to the production environments and product objectives—and the knowledge of the software provider. The creation of the FRA of the system is also achieved in cooperation. This course of action offers a complete and omission-free risk assessment. In the same way, identified potential sources of risk can be quickly reduced. The documentation developed during the course of this cooperation provides the right test steps with which the IQ, and later on the OQ, can be carried out. The close cooperation between the operator and the software provider during the validation process doesn't just have a qualitative benefit, it also helps to (1) conserve human resources at the operating company and (2) to drastically reduce the amount of time that would otherwise be needed in order to complete the process. As shown above, this optimized approach of carrying out system validation provides the possibility of quickly and regularly carry out a Performance Qualification. In addition, the process of installing updates of new and improved software versions can be carried out quickly and resource-efficiently in cooperation with the developers of the software solution.
Robert Glaser is the CEO of AUVESY Inc.
