| Comment Record |
|
Commentor |
Mr. Wolfgang Winter |
Date/Time |
2001-12-21 09:11:08 |
|
Organization |
Agilent Technologies Deutschland GmbH |
|
Category |
Company |
| Comments for FDA General |
| Questions |
|
1. General Comments
|
Section 5.1
Original wording:
Other factors not specifically addressed...
Discussion:
The technical examples (scanner resolution, scalability, operating environment) are areas that are covered in the technical specifications of a manufacturer and have to be addressed during operational qualification and performance verification.
The trustworthiness and reliability of electronic records can be severely affected by other factors that are typically not covered by technical specifications and OQ/PV. For analytical systems and devices, this can be the case when a device is controlled from software package developed by a different manufacturer and where the communication protocol (drivers) are not public domain. The lack of a support agreement between the software vendor and the device manufacturer can affect the trustworthiness and reliability of the electronic records generated by the system.
Recommended wording:
add the following example:
- Devices controlled by software: The reliability of the communication between the device and the control software may be affected by the communication protocol implementation in terms of error detection, handshake communication and official support of the software developer by the device manufacturer.
Section 5.4.2
Original wording:
Structural testing....
Discussion:
The terms structural testing, white-box testing,black-box testing are not defined in the glossary.
The paragraph appears to indicate that structural testing (white-box testing) is limited to code and document inspections.
While the reviews are absolutely necessary for the software development team, they are not practical for the end-user of a large, complex software system.
However, this is only one piece of this test approach. In the literature, these tests are called structural test cases (e.g Hetzel) and systematically cover a system's logical structure. This knowledge is obtained by inspecting the source code. Ideally, these test cases are developed along with the code. Modern testing techniques allow performing white-box tests automatically through appropriate test engines once the so-called test harnesses (test interfaces and test beds) have been implemented by the software developer. This technique is particularly relevant for modern, object-oriented software products where internal data integrity can hardly be ensured through black-box testing alone. Test engines can be made available by software manufacturers to end-users to execute regression testing on the system.
Recommendation:
Replace the original paragraph on structural testing with the following statement
This testing usually includes inspection (or walk-throughs) of the program code and development documents, as well as executing tests that have been specifically designed based on the logical structure of the software code. The goal is to provide a high degree of assurance for the integrity of data even during normal operation and under boundary or error conditions.
Section 5.4.3 How test results should be expressed
Discussion:
The paragraph does not adequately reflect that test cases and test results must be documented together.
The requirement for quantitive vs. qualitative test results is stated in an ambiguous way. Qualitative (pass/fail) information is important to document and review test status and progress during the validation phase. A test result has to be either pass or fail based on the quantitative measurements obtained during execution of the associated test case and the acceptance limits.
Recommendation:
Reword the paragraph to state
Quantifiable test results should be recorded using the measured, quantitative result, the acceptance criteria as well as a qualitative result such as Pass/Fail information.
Section 5.6. Extent of Validation
Discussion:
This paragraph attempts to define guidelines for the extent of validation required for complex systems. However, the statement a more complex system might warrant a more comprehensive validation effort is very true, but not helpful from a practical perspective.
Recommendation:
Include a categorization of systems to provide guidance on the appropriate validation approach.
The recently released GAMP4 Guide has laid out how the validation approach for the different categories may be used along with risk and supplier assessment (see appendix M4). The categorization could be based on GAMP4 Appendix M4.
Section 5.8. Change Control (Configuration management)
Discussion:
The paragraph does not recommend how service providers should document revision changes.
For the end user it is important to understand the conventions used by the supplier (e.g. how changes are identified) and to obtain official information in the form of service notes, release notes, software status bulletins and a documented revision history.
Recommendation:
Add the following statement to the 2nd paragraph.
The documentation provided by the service providers should follow consistent conventions and be provided in an official format such as service notes, release notes, or software status bulletins. For example, hardware systems should be identifiable through unique serial numbers and software/firmware systems should be identifiable through unique revision codes
Section 6.1.1 End User Requirements Specifications
Original wording:
If possible, the end user should obtain a copy of the developer's requirements specifications for comparison.
Discussion:
The term developer's requirement specification is misleading and has been interpreted as a request for design/development specifications such as external reference specifications (ERS) or internal reference specifications (IRS).
For complex software projects with a wider scope than a lab-specific in-house implementation (e.g. for worldwide use), these documents are typically written for developers (e.g. software design engineers) as target audience and are typically not be useful to end-users.
The guidance should specifically ask for the specifications document that corresponds to the User Requirement Specification compiled by the end-user's organization (see GAMP4 Appendix D1). These documents may carry titles such as functional specifications, system requirement specification or product specifications, but generally describe system capabilities from a user point of view.
|
|