This is an example process for validating a system:
The Validation Plan is a document that outlines the process that will be used for validating a specific system. The plan will discuss the specific risk of the system and outline the documents that will be written (how many SOPs).
These documents will outline the specific requirements of a system. Typical items covered in a Functional Requirements documents are: User Roles, User Access, Process Workflow and 21 CFR Part 11 Requirements (Audit Trail, Electronic Signature). Example template
These documents are crucial to a successful system validation. Requirements must be written concisely represented. The example below uses content for an Audit Log:
Audit Log report
a. User that made the change
b. Reason for change
c. Previous Value
d. New Value
e. Date/Time of Change
This document will outline the necessary hardware and architecture for a system.
A Design/Configuration Document will outline how the specific software was designed and include any specific configuration.
Installation Qualification verifies Server Requirements were met and also verifies the Design/Configuration of the software.
This document "tests" the Functional Requirements document. It will include challenge testing. It is important to ensure all error messages display as necessary. This testing also ensures the workflow is as intended.
Final Validation Report
The Final Validation Report summarizes the testing (including deviations) and is used to release the software for production use.
After validation has been completed, all changes to the system must be maintained through a change control process. Here are example templates of information necessary for a compliant change control process:
More references for validating systems and 21 CFR Part 11:
-Inspections of Sponsors, CROs and Monitors
-Guidance for Industry Computerized Systems Used in Clinical Investigations
-General Principles of Software Validation; Final Guidance for Industry and FDA Staff