System Configuration Document: a key component of validation that should be in place before system release
A System Configuration Document captures the final state of configuration of the system being validated. This state should be reflective of the initial usage environment that will be in place at the time of system release. Some of the key areas to be aware of are as follows:
- Reflection of Usage
- Level of Detail
- Change Control
- System Restore
- Audit Impact
This post is relevant to anyone performing an equipment or system validation.
When should a System Configuration Document be completed? Some might argue that it should be developed in parallel with the User Requirements Specification (URS) after initial system identification or development. Others would argue that it should only be in place prior User Acceptance Testing (UAT) / Performance Qualification (PQ) testing. The bottom line is that is should be in place once the system is developed/identified and the URS is approved. At a minimum, a draft version of the System Configuration Document should be in place prior to any usage testing. This document will be utilized to provide the defined configuration of the system necessary for testing. It can and should be updated to reflect the outcome of usage testing as necessary if issues are discovered with the current configuration.
DO NOT wait until after release of the system to create this document. Further details of why this is not appropriate will be discussed during the Change Control section.
Reflection of Usage
It seems pretty obvious that the System Configuration Document would reflect the actual usage of the system. It is important to mention here that accuracy is the key to a success. Make sure that the System Owner is involved in this process as a final check to confirm the document matches what is current within the system. It may be necessary to include other individuals within the process for a complex system with boundaries that may impact other systems or groups (i.e. IT Staff, Engineering, QC/QA, system SME, system vendor, etc…).
Level of Detail
My opinion is the more details, the better. It will take a bit more effort up front to capture all the details of the initial configuration of the system but it is critical information that can be utilized during change control, system restore, and system audits. Include diagrams, screenshots, tables, and pictures as necessary. The document should allow a user with basic system knowledge to reproduce the configuration of the system.
A mentioned earlier Change Control is an important reason for the proper creation of a System Configuration Document. Change Control captures all changes to validated systems. A System Configuration Document provides the initial starting point or baseline of the system. It should be possible to track all changes to a released system back to the System Configuration Document. The System Configuration Document can be formally revised once the system is released to reflect the current state of the system per Change Control.
Another important and overlooked function of a System Configuration Document becomes apparent when it is necessary to perform a system restore. This easily applies to software but should also apply to equipment if it becomes necessary to replace equipment or a system due to disaster or other reason. A well-written document can help to restore the system to its previous configuration in a much shorter timeframe with a high level of confidence and minimal production disruption.
Audits are perhaps the main reason for proper System Configuration Documents. Effective System Configuration Documents show an auditor that quality planning were part of system validation. Change Control is often a central part of any system audit. As stated earlier, it is easy to trace the history of the system back to system release with a quality System Configuration Document. And with an updated System Configuration Document, it is easy to show the current configuration state.
I welcome any and all feedback on my posts.
If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com (this format is to prevent auto spammers).