Tuesday, 11 May 2021 14.00 - 15.30 h
GMP News Nr. 136
9 October 2001
|FDA Draft Guidance for 21 CFR Part 11|
On September 24, 2001 FDA published two Draft Guidances for Industry for 21 CFR Part 11, Electronic Records, Electronic Signatures. The first Guide contains a glossary of terms for 21 CFR Part 11. Many of the terms listed there refer directly to 21 CFR Part 11. For the definition of "off-the-shelf software" the Guide refers to the definition of the FDA Center for Devices and Radiological Health: "A generally available software component for which the user can not claim complete software life cycle control". The validation of these commercially available standard programs takes up a large part of the 2nd Draft Guidance on the topic of validation. You will find more details in this article.
Perhaps one of the lesser known terms is "Regression Analysis and Testing". It is defined as: "A software verification and validation task to determine the extent of verification and validation analysis and testing that must be repeated when changes are made to any previously examined software products".
Without a doubt the 2nd Guidance for Industry on "Validation" will be of greater importance. 5.1 underscores the significance of the "System Requirement Specifications" within the framework of the validation. FDA says: "Without first establishing end user needs and intended uses, we believe it is virtually impossible to confirm that the system can consistently meet them". With regards to "System Requirement Specifications" it also says that other factors not mentioned expressly in Part 11 may also have a effect on electronic records. For this reason, system requirement specifications must also be drawn up for such factors.
As an example for this the Guide mentions, for instance, the scanning of paper documents (e.g. batch processing records). This requires the evaluation of resolution, speed, colour accuracy, hardware and performance with respect to their effects on electronic records. The requirements as regards scaleability (in a network environment) and the ambient conditions (e.g. electromagnetic interference and temperature/humidity) are also to be defined and then checked later within the framework of the validation.
In 5.2 the Guide lists the necessary documents for the validation of a system in accordance with Part 11. It names a "Validation Plan" as a "strategic document" which defines what has to be done, the time-table for the validation, what tasks have to be executed and who is responsible for the validation. Like the two other documents, this plan should be "reviewed and approved by designated management". The "Validation Procedure" should contain detailed steps for the implementation of the validation, including the system configuration, test methods and acceptance criteria incl. the expected result. Finally, the "Validation Report" should summarize the results of the validation. Whenever possible, quantifiable parameters should be given here instead of "pass/not pass".
5.3 "Equipment Installation" requires that before starting the validation the hardware and software be correctly installed and the necessary documentation, e.g. user manuals, SOPs, specification sheets, etc. on hand.
5.4 "Dynamic Testing" lists the general conditions for conducting the tests. It lists: test conditions (normal and stress conditions), simulation tests (with simulation program) as well as life user-site test (under the existing conditions for use of the system). The tests themselves are differentiated into structural tests (white box testing), functional tests (black box testing) and program built tests (module, integration and total program tests).
The Guide emphasizes that dynamic testing is an important part of the validation, but does not on its own constitute a validation. For this reason the static verification techniques, and these include e.g. source code reviews, are absolutely necessary. If the results are good the scope of the functional tests can be reduced. The scope of the validation for a Part 11 system depends essentially on the risk for the program for product safety, efficacy and quality. Furthermore, the risks as regards data integrity, authenticity, confidentiality and system complexity are to be taken into consideration.
5.7 requires that the review be independent. This can be achieved by involving external parties (third party) or by organizational partitioning.
As regards change control (configuration management) special attention is paid to the monitoring of suppliers and their upgrades, fixes and service packs. Here regression analysis and regression tests are mentioned as an "extremely important tool" (see definition at the beginning of this article).
The section "Special Considerations" contains detailed remarks concerning commercial, off-the-shelf software. The necessity for it to be validated is expressed by the statement "We do not consider commercial marketing alone to be sufficient proof of a program's performance suitability".
Although it goes on to say "However, the end user's validation approach for off-the-shelf software is somewhat different from what the developer does".
The requirement mentioned under 6.1.1 will be difficult to implement. If possible, the user should obtain a copy of the developer's requirement specifications. (This will be very difficult - Author's remark)
As regards the structural integrity of the software the Guide requires that if the source code is not available for the check the following measures should be initiated: 1. Investigations on the program history and 2. "preferably" auditing of the software manufacturer As regards the functional tests of off-the-shelf software it is said that extensive tests are necessary here if a review of the source code is not possible. (This will be the rule Author's remark). The second point of "Special Considerations" concerns the Internet, in particular the transfer of electronic records. The statement: "We recognize that the Internet, as computer system, cannot be validated because its configuration is dynamic" is to be understood as a clear statement.
On this basis the Guide specifies that it is extremely important to conduct a validation of sender and recipient paying special attention to the accuracy, completeness and punctual transfer of data and records.
The annexes to the Guide mention a large number of publications for the interpretation of software which help with the implementation of 21 CFR Part 11.
We hope that these "personal" comments on the Draft Guidance will be of assistance to you.
Author: Oliver Schmidt, CONCEPT HEIDELBERG