Risk Based Validation (RBV) was sanctioned by the FDA (along with EC and WHO) as soon as it became obvious that the scope of any validation task must be allowed to be adjusted to avoid over burdening companies with repetitive and or unnecessary tasks. However this was not meant to reduce validation intensity;  only to render it more appropriate and targeted. The final defined scope of risk based validation activities must still be reviewed to verify it's adequacy.

We are all aware that risk assessment’s come in many formats; for instance, we have on our site a fully detailed; Failure mode and effects analysis (FMEA) template, which we use for all aspects of concept development and design development.

The Validation Online risk based validation - Online Risk Assessment (VRA) is a very different document and was specifically designed to assess and define the appropriate scope of any validation task. As such; it is a very important document which is mandated by the FDA and regularly reviewed by them. Is the scope of your validation adequate? Is probable the most important question in validation and the VRA must give assurance that it is.

The pit-fall(s) of using multiple event Risk Assessments (such as FMEA’s) is simply that there are not (in validation) multiple variations or answers available. At the validation stage the system / process / equipment / program has already been bought / built / written / installed and commissioned. All aspects of design / functionality / safety / operability will have been fully debated and integrated at the URS stage and reviewed and approved at the DQ stage.

Validation is the number one priority in most modern facilities, fall down on your validation and the regulators (FDA / MHRA / EMEA) can fine you, remove your approval to manufacture, or even close you down. Losing your manufacturing rights for a drug that has taken hundreds of millions to develop, is catastrophic, even to the major international companies. Good risk based validation ensures that this does not happen. 

Validation is a mixture of skills, and the manual  is designed to interlink with your existing skills and add the required mix of Quality, Instrument, electrical and mechanical knowledge to enable you to work as a validation technician or engineer or consultant in the pharmaceutical or biotechnological or API or Medical Device, industries. In validation you are not designing, you are verifying that equipment or installation conform to certain standards.

This involves authoring a document train that starts with the URS follows with IQ / OQ and usually finishes with the PQ, normally difficult and complex documents - but in your case - they are all in the manual Corporate Validation Manual DVD, ready for you to download. Using the manual is a great way to receive training while maintaining  full time employment, and to feel confident that the manual has the answers or can point to where the answers are for any validation problem you may run into.

Whenever a new installation or changes or modifications are to be made to equipment used within a 21 CFR Part 210/211/820 compliant manufacturing, testing and or storage facility; a Validation Planᴬ⁴ (VP) must be initiated in order to document and authorize all the attendant responsibilities, scopes and associated requirements.  This VP will also define whether the proposed change will use a single User Requirements Specificationᴬ¹ (URS) document for the change, or individual URS documents for all associated equipment allied to this proposed change.

The URS is such an important document that you can always be certain that time spent ensuring it is put together correctly, will pay dividends later in the risk based validation process.  Initially the document will contain the high level requirements of the end user; laid out in a clear and unambiguous manner.  In the URS each of these requirements must be detailed in a manner that will render them verifiable by the execution of a testing or inspection procedure.  This high level document is titled URS-Level-1.  The requirements in this Level 1 document must subsequently be broken down into activities.  Then these activities must be further broken down into direct tasks and support tasks.  This is an engineering responsibility and produces URS-Level-2.  If the system uses software, the tasks detailed in URS-Level-2, must be translated into lines of code by the software writer, these lines of code must be attributed and constitute URS-Level-3.

These URS Level 2 and 3 documents were once part of the Functional Specificationᴬ⁷ (FS), however the mandated requirement for traceabilityᴬ⁷ from each requirement in the URS to the actual verification of compliance inspections or tests in the Performance Qualificationᴬ² (PQ), forced a step change to be initiated to enable compliance with the Full Life Cycle Requirements in risk based validation.  Prior to this change; detailed traceability between the URS and the Design Specificationᴬ⁵ (DS) had become difficult if not impossible to achieve.  The use of levels of URS now reinstates the required traceability and engenders good testing between design and protocol verifications.  During these activities the URS must be maintained as an active document with each (of the 2 or 3) stages being reviewed and approved on completion.   

With the URS completed and approved, the procurement process can commence.  When the successful design (or product, if off the shelf item is chosen) is known, its design must be subjected to the execution of a Design Qualificationᴬ³ (DQ) which will be used to verify that this proposed procurement will satisfy all the documented requirements in the URS.

The completion of the DQ allows the procurement process to complete and the ’hands on’ stage of the risk based validation process to commence.   Next we must execute a Validation Risk Assessmentᴬ⁶ (VRA).  This is often the most abused and misunderstood document in the validation process.   The VRA is in place because the regulators have decreed that we must produce, and hold for regulatory inspection, a documented justification for the scope of validation activities we have deemed to be appropriate in our planned risk based qualification.  They expect this justification to take the form of a risk assessment.  This makes the VRA a very meaningful document. Your VRA must consider all the regulatory requirements and define a level of risk based validation intensity that is cost effective to the end user, while being appropriate to the sophistication of the equipment and acceptable to the regulatory authorities.

Since the execution of the VRA will define the scope of validation; its execution, will allow the protocol authors to commence authoring the Installation Qualificationᴬ³ (IQ), the Operational Qualificationᴬ⁵ (OQ) and the Performance Qualification (PQ). All based on the findings of the risk based qualification execution.

ᴬ¹ User Requirements Specification

ᴬ² Performance Qualification.

ᴬ³ Installation Qualification

ᴬ⁴ Validation Plan

ᴬ⁵ Operational Qualification

ᴬ⁶ Validation Risk Assessment

ᴬ⁷ Traceability