Validation Document Requirements

  

 Email Article  

Tweet  

  

  

Documentation is important to demonstrate system validation. The documentation should include a written design of what the system is intended to do and how it will do it. Process Validation is a legal requirement and enforceable under the following guidelines: 501(a)(2)(b) of FD&C Act and cGMP guidance –ICH Q7.

In essence, 21 CFR Part 11 addresses how any electronic data and associated records generated within the regulated environment are to be properly stored, secured, archived, validated and maintained. 21 CFR Part 11 directly applies to all FDA’s regulated segments, with GLP and GMP, and has hence been enforced by regulatory centers such as CDER and CBER.

A written validation or test plan should be developed to include structural and functional analysis.

Test results and evaluate the data to demonstrate that the specification of the system was met.  The computerized system validation protocol may contain a summary with the following outline or checklists:

1. Introduction (defines the validation scope)
2. Justification (defines the agency or compliance documents under which the validation is run)
3. Name of the person that developed the protocol and the date
4. Regulatory References
5. System Description: Software includes media and hard-copy listings of all table structures, methods, procedures, libraries, forms and graphics. And hardware includes hardware Configuration, operating instructions, wiring diagrams, and cabling requirements.
6. Testing Description: procedures for determining functionality, limits, etc.
7. Documentation: Standard operating procedures (SOPs), validation Documents, system-Related documentation, and testing documentation.
8. Validation Report:

The validation protocol should also guarantee that changes in the system such as equipment upgrades, replacement of components, or new tools will keep the reliability of protocols and electronic data.

The documentation should contain a review of changes to ensure that a re-validation will take place when changes are significant enough to threaten the integrity of the data.

Off-the-shelf purchased software should be validated by the company that wrote the software. The documentation of this validation should be available. Appropriate tests and challenges should be developed to establish the suitability of a computerized system.

Click Here for Validation Case Study

The scope and depth of the validation depends on the risk analysis evaluated during the validation protocol design. The validation scope also depends on the complexity of the system.

The validation should be sufficient to support a high degree of confidence that the computerized system will consistently perform to the design specification. Many of the separate components of the computerized systems are tested separately before being placed in the computerized system.

Validation should be done with all components in place. Validation should define unexpected conditions and events. The validation should be done under maximum loads and worst-case scenarios. It is important to determine that under worst-case scenarios software routines consistently perform as they are supposed to.

The validated system should include a validation protocol, test results, and test reports, including individuals who conducted the testing, reviewed the data, and approved the validation. If the validation was done by an outside vendor, keep copies of the data on site, including design specifications, protocols, general results, and validation report.