The Validation Process



This chapter looks at the validation process.
Note: This validation process is used to validate a specific computer system. It may be done on an existing computer system or on a new computer system.


The purpose of the validation process is to provide a high degree of assurance that a specific process (or in this case computer system) will consistently produce a product (control information or data) which meets predetermined specifications and quality attributes.

The Validation Facets

The validation effort consists of 5 specific facets or processes, each alone, would not constitute a validation.  However, depending on the specifics of the application, system or process, would depend on which facets would be required.  There following facets are:
·  The Validation Master Plan (VMP)
·  The Project Plan
·  Installation Qualification (IQ)
·  Operational Qualification (OQ)
·  Performance or Process Qualification (PQ)

Types of validation

The two types of validation are:
·         Prospective validation: the validation of a new system as it is developed
·         Retrospective validation: the validation of an existing system

Validation process
The validation process and document references are shown below:
Establish Team(s)
Determine Validation Activities
Write the Validation Protocol
Specify the System Development Details
Perform Qualification Activities
Develop/Review Controls and Procedures
Certify the System
Review Periodically

Steps 1 to 8


This topic provides an overview of the validation process.

Step 1:
Establish team(s)

The first step in the validation process is to establish the System Validation Team and if required the System Validation Steering Team.
These are the teams that will be responsible for the validation process.

Step 2:
Determine validation activities

The second step in the validation process is to determine and record all of the validation activities that will be undertaken in order to validate the computer system.
The validation activities are the exact details or activities that will be required for each of the steps in the validation process. The output from this activity will be the Validation Plan.
Example: At step six of the validation process (Develop/Review Controls and Procedures) the exact controls and procedures that will be required to keep the computer system validated will be determined and recorded.
Note: The type and number of validation activities will depend on the nature of the computer system that is being validated.

Step 3:
Write the Validation Protocol

The third step in the validation process is to write the Validation Protocol.
The Validation Protocol describes the procedure and the steps within the procedure that will be followed in order to validate the system.
The Validation Protocol must also provide a high level description of the overall philosophy, intention and approach.

Step 4:
Specify the system development details

The fourth step in the validation process is to specify the system development details.
You should specify to the supplier or developer of a system that they must have:
·         a good methodology in order to develop a system
·         a formal quality management system for the development, supply and maintenance of the system
You may need to specify to the supplier or developer the types of items you want to see - this could be done in the form of a Quality Plan. These items will help you ensure that the supplier or developer has a good methodology and formal quality management system in place.
Items that will help you ensure a good methodology and formal quality management system include:
·         quality management procedures
·         life cycle definition
·         specifications, for example user requirements specification and functional specification
·         documentation controls and various items of documentation, for example user manuals and administrator documentation
·         testing procedures

If the computer system is a new one, then the system development requirements will be identified prior to system selection/development.
If the computer system is an existing one, then the system development requirements will still be identified and used as a basis against which to evaluate the system.

Step 5:
Perform qualification activities

The fifth step of the validation process is to perform the qualification activities, which are comprised within the validation process.
Some examples of these qualification activities include:
·         Supplier audit
·         Specification qualification
·         Design qualification
·         Installation qualification
·         Operational qualification
·        Performance qualification

Step 6:
Develop / review controls and procedures

The sixth step of the validation process is to develop/review controls and procedures.
If the computer system is a new one, then you will need to develop the controls and procedures, or check the suitability of existing generic procedures applicable to the site or department.
If the computer system is an existing one, then you will need to review the controls and procedures and update them if required.

Step 7:
Certify the system

The seventh step of the validation process is to certify the system.
This step is where you certify that the validation deliverables have met the acceptance criteria that were described in the Validation Protocol.
When you certify the system you should prepare a validation report. The validation report should outline the details of the validation process.
Examples of details that should be outlined include:
·         what was done and the results that were obtained
·         any special considerations
·         whether the validation procedure (as described in the Validation Protocol) was followed
·         a summary of all documentation that was generated
·         the location of the validation documentation
·         the retention period for the documentation

Step 8:
Review periodically

The eighth and final step of the validation process is to review the system validation periodically.
The system should be reviewed periodically to provide additional assurance of validation.
There should be documentation outlining the details of how the review is to be done and what the review should cover.
The end result of a review should be a summary of the review and a recommendation as to what to do next.

Timing and Documentation


This topic looks at the timing of the validation process and documentation.


Ideally, the validation process begins at the inception of the system selection or design process. It then proceeds alongside the system development and is completed prior to implementation of the system.
Many aspects of computer systems validation are just "Good Informational Resources (IR) Practice" and as such should occur anyway during the implementation of a system.
For many reasons, a system may not have been validated until after it has been in use for some time. The basic validation process is the same as for a new system. The timing of some of the validation activities may, however, differ.
Note: Retrospective validation is becoming increasingly unacceptable to regulatory inspectors. New systems should be validated before use.

Timing for a new system

The steps in the validation process, and their associated validation activities are performed in parallel with the system development life cycle and reference the development documentation as it is produced.

Timing for an existing system

For existing systems, the validation activities will still follow the development life cycle but will reference the development documentation retrospectively.


An example of the parallel between system development and validation activities is shown below.
* Functional Specification can comprise mechanical, electrical and software functional specification for systems embedded in equipment
** Systems embedded in equipment with significant control and monitoring instrumentation
*** Testing carried out by supplier can form part of subsequent qualification activities if adequately controlled. This can help reduce the amount of testing needed later, particularly at operational qualification.


Every step in the validation process, and the activities within the steps, requires documented evidence that the steps or activities have been completed.
The table below shows the documents that must be generated at each step.
Note: In some cases some of these documents may not be required.

Documents Generated
Establish Validation Team(s)
·         Team Charter
·         Terms of Reference
·         Role Definition
·         Team Organization Chart
Determine Validation Activities
·         Validation Plan
Write the Validation Protocol
·         Validation Protocol
Specify the System Development Details
·         Systems Development Life Cycle documentation
Perform qualification activities
·         Supplier Audit Report
·         In-house Audit Report
·         Source Code Review Report
·         Specification Qualification Report
·         Design Qualification Report
·         Installation Qualification (IQ) Protocol
·         IQ Results
·         IQ Summary Report
·         Operational Qualification (OQ) Protocol
·         OQ Results
·         OQ Summary Report
·         Performance Qualification (PQ) Protocol
·         PQ Results
·         PQ Summary Report
Develop/Review Controls and Procedures
·         SOPs (Standard Operating Procedures)
·         Training procedures
·         Training records
Certify the System
·         Validation Report
·         Validation Certification
Review the System Validation Periodically
·         Periodic Review Procedure
·         Periodic Review Audit Report


宗伊旺博 said...


啟佐 said...

女傭調教 女生自衛 夫妻交換 大腿內側 夜未眠成 嘟嘟情人 嘟嘟圖片 同志色教 吉澤明步 台中夜店 台北夜店 台灣同志 台灣ki 出包王女 凹凸電影 凌虐俠女 免費女同 免費女傭 免費圖片 免費同志 免費動畫 免費黃色 免費貼影 免費色片 免費dv 免費線上 -qq美美 jp素人 h文小說 辣媽寫真 辣媽哺乳 黃色珍藏 麗的線上 貼圖片區 高雄夜店 視訊kk 西洋美女 電影線上 阿賓小說 阿賓色慾 蓬萊仙山 色片直播 美女自衛 美國色片 美美色網 線上收看 線上動畫 素人寫真 素人大全 短片線上

customerspecifics said...

Finding customer specific requirements has long been a challenge. In fact, a survey of current automotive suppliers found that a significant number did not know where to go for the latest applicable customer specific requirements. For registrars and end users, this represents a serious problem. How can rules be followed and enforced if they are not readily available?

It is with these challenges in mind was created. Here you will find a community to access, share, and discuss customer specific requirements.

Please understand that the content of this site will take some time to develop as we work hand in hand with each of you to build a comprehensive database of the thousands of available customer specific requirements. We ask that you join us in our cause as we attempt to build something great for the common benefit of the quality community.

Anonymous said...

請繼續發表好文!加油加油再加油! .................................................................

冠慧 said...

nice to know you, and glad to find such a good artical!......................................................................

Anonymous said...


Anonymous said...