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.
Download addresses:
http://www.fda.gov/cber/gdlns/esigglos.pdf
http://www.fda.gov/cber/gdlns/esigvalid.pdf
Author: Oliver Schmidt, CONCEPT HEIDELBERG
|
