Validation Reviews user requirements

Do the design controls ensure that design reviews and design verification and validation are recorded and demonstrate the product meets the design input and user requirements ... 

The performance of an instrument should be reviewed on a regular basis to ensure that the instrument is reliable and continues to comply with the requirements specified in the user requirements. The review should determine whether the instrument is maintained in a validated state. The review should include records for use, maintenance, services, and performance verification testing. In case the records indicate that the instrument is more prone to certain types of failure, preventive maintenance may be desirable to avoid system failure during operation. The review can also provide useful information to prioritize instrument replacement. 

User requirement specifications cover more aspects than only the GMP requirement, because the URS is not written only for the validation procedure in fact, a URS is a very important project document covering technical as well as economic requirements of the technical system. Pharmaceutical manufacturing departments not only check the GMP aspects of a system additionally, following good engineering practice they will review the technical and economic aspects of a technical system. Obviously, the more experience a company gains, the more comprehensive a URS become. Past experiences such as project faults, inefficient technical systems, and bad commissioning can be included in a URS. 

D1 Data review, verification, and validation D2 Validation and verification methods D3 Reconciliation with user requirements... 

User Requirements Specification Functional Specification Configuration Details Design Review Installation Qualification Operational Qualification Performance Qualification Validation Report Change Control... 

SAS The SAS Institute support organization has recently published resources for both validation (21) and actual IQ/OQ guidance (22). This should certainly be reviewed as a plausible starting point for the OQ. The same advice regarding analyses from standards organizations (15) applies. Please note that both S-Plus and SAS provide a wide range of capabilities for model creation, data analysis, presentation, and interfacing to databases and other software. It is incumbent on the user community to identify, at least initially, the capabilities that will be utilized in the user requirements documentation. Such software-specific capability should then be appropriately tested in the OQ. 

The user requirements are used to generate the validation or acceptance tests. The system requirements are used to generate the system tests. The user requirements document is reviewed. After it is considered to be free of errors, the system requirements document is generated from it. The system requirements document is more detailed than the user requirements document. This document is input to the system architecture specification document. This document is at a very detailed level and describes the architecture of the system. For more complex systems, the architecture specification document is further detailed into component or sub-system specification documents. Once the architecture of the system is defined, the implementation phase of the system can start. 

Testing must include, but not necessarily be limited to, the activities listed below nnder the topics of Development Testing and User Qnalification. However, the use of these qualification names is not compulsory. Due account must be taken of any test requirements identified by the Validation Plan, Supplier Audit, and Design Review. Testing mnst not be condncted against an unapproved specification. 

A validation protocol is a documented, pre-agreed sequence of activities that are to be executed by a nominated team of people who are to review and test the computer system or part thereof. The objective of the protocol is to provide documented evidence that the system is installed correctly and will operate reliably and consistently to meet all user and regulatory requirements. 

Each intent level contains information about the characteristics of the environment, human operators or users, the physical and functional system components, and requirements for and results of verification and validation activities for that level. The safety information is embedded in each level, instead of being maintained in a separate safety log, but linked together so that it can easily be located and reviewed. 

---