A properly designed and precisely executed VRA analysis has proved over and over again to be key to the expedient completion of any FDA, WHO and or EU compliant; risk based validation project. Our latest issue of this Risk Mitigation in Validation template (RMV) document (issue 11) reflects these principles and also incorporates the very latest in regulatory mandates and legislative guidance document comments. The execution of this VRA not only defines and documents the scope of your validation activity; it also prompts you into documenting how each Part 11 record is evaluated and how it will be managed. This brings you into compliance with the mandate in the latest Part 11 clarification documentation. This is now a mandatory requirement and these justifications form regulatory reviewable documents.

This new found freedom to assess records and set justified management of them would appear to mean that the original all embracing approach to all electronic records is to be dropped and the full rigors of part 11 applied only to the data that directly affects product quality, safety, and records (of the product) integrity.

"For those records that are to remain the subject of part 11, we will apply discretion in the validation of audit trails, record retention, and record copying."

This would appear to mean that if your in-house document control is secure and robust; then it will be acceptable in the matter of audit trail / record retention and record copying.

"We will enforce all predicate rule assessments, including predicate rule record and record keeping requirements."

This is a statement to the effect that in all other ways 21 CFR Part 11 will be enforced.

Accordingly, we recommend that, for each record required to be maintained under predicate rules, you determine in advance whether you plan to rely on the electronic record or paper record to perform regulated activities. We recommend that you document this decision (e.g., in a Standard Operating Procedure (SOP), or specification document).

This is a new requirement for a database of predicate (all) data records, giving a documented and approved justification for the method of storage.  Basically separating them into section such as number:

1.         Is not predicate data.

2.         Is a predicate data, not require to be stored in compliance with Part .

3.         Is predicate data, must store compliant current Part 11 requirements.

New Interpretation:

A predicate data record does not required to be Part 11 compliant; unless it is the master copy of the predicate data and is stored in an electronic format. 

I.E. if the record is derived from an electronic source and is downloaded into a hard copy format; which then becomes your master copy of the record.  This paper copy is not subject to Part 11 requirements; but must comply with all the other rules and regulation governing the management of predicate data records.

The question - How much validation? - has been an open subject for many years. Numerous companies brought in validation consultants, and or regulatory compliance experts, to guide them through these problems, but every so often, there would be clashes, or at least variations in opinion, in what the appropriate scope and depth of validation was. It was understood and accepted by the regulators that there was equipment in use, that full validation was inappropriate for, yet the design or misuse of that piece of equipment could affect product quality, so some degree of validation was required.

The more typical production equipment is mainly mechanical (but often intricate and complex), but frequently uses electronics to monitored and or managed it’s functionality and or record retention systems. Then at the very pinnacle of validation we have the mainly electronic systems running extremely complex sophisticated software programs or systems where the software manipulates data and accepts or rejects product quality base on the outcome of the data manipulation. All these systems play a major role in the product manufacturing process, they all require thorough validation using the existing framework of IQ – OQ - PQ, but they do not all require the same level of Risk Mitigation in Validation template. How do we define the appropriate level?

Risk Based Validation

When we move away from these simple devices, to the average type of production equipment. Here we find a range of equipment varying from purely mechanical (but often intricate) equipment, to mechanical equipment assisted and or monitored and or managed by some degree of electronics. Then at the very pinnacle of risk based validation we have the mainly electronic systems running extremely complex sophisticated software programs. All these systems play a major role in the product manufacturing process, they all require thorough Risk Mitigation in Validation template using the existing framework of IQ – OQ - PQ, but they do not all require the same level of validation. How do we define the appropriate level?

First we have to look at validation and how the level of validation can be varied independently of the scope. If we list all the tasks we consider essential to complex software driven equipment validation, then drop off the tasks we consider inappropriate to the next level of equipment complexity, and so on. We appear to have four levels, with a significant step change between each of them.

• Mechanical/electronic/electrical/full life cycle software, validation.
• Mechanical/electronic/electrical/software, validation.
• Mechanical/electronic/electrical/software, calibration.
• None

The requirement for 21 CFR Part 11 compliance, can occur at all three of the upper levels of validation and so is addressed in the Risk Mitigation in Validation template as a separate requirement. To find that a piece of laboratory equipment requires the same degree of validation as a Distributive Control System may be disquieting, however any equipment that uses software alone, to automatically derive whether the product passes, or fails to pass, an inspection stage, must be subjected to FLCV. The laboratory equipment may have one such stage, the DCS will have many, however, one or many, the software lineage for each system, must follow similar methodologies.

Our Risk Mitigation in Validation template (VRA) takes you through this assessment process and enables you to make a documented and justified decision as to the level of validation each piece of equipment will receive. This fulfils your obligation to ensure that all software is assessed, as to FLCV applicability.