Validation Steps

Why bother?

Why would you do process validation? It is time-consuming and expensive. As a producer of healthcare products, you must guarantee that the product fulfils the set specification. The first until the umptieth product. You wouldn’t need to validate the process if you tested each product on all specifications. You can guarantee product quality when you perform 100% verification. This can be done for low-volume production and non-destructive testing. The production process must be validated when 100% verification is not possible or preferred. Validation provides us with the confidence (to a defined confidence level) that all products match the defined specifications.

Or, the less motivational speech: You have to do it if you want to be ISO 13485 compliant!!

Where to start?

Before validating a production process, you must define your product and record this in product specifications. The product is developed with a   controlled design process (according to Design and Development as described in ISO13485. Please read this article on D&D) with the product specification as D&D output. A product specification contains all information about the product (dimensions, mass, or functional specifications including tolerances), test specifications and frequencies, acceptance criteria, sampling plan, raw materials, sterilization, packaging, storage, retention samples, etc. You don’t need all information ready when starting the validation process; this can be defined in detail.

Secondly, you need a production process. Maybe this process is not entirely stable yet, but that can be fixed in the Engineering Study. You can start.

Equipment or process validation

Let’s say you want to dry your product in an oven. During the equipment validation, you test if the oven performed as the manufacturer promised. When you set the temperature at 80 degrees C, is the temperature at every location in the oven 80 degrees and constant over time? This must be proofed using, for instance, calibrated dataloggers. In this way, you test all the functions of the oven. This is part of the equipment validation. Many equipment manufacturers provide protocols to perform equipment validation.

Testing the efficacy of the drying process for your product is process validation. What temperatures and times result in the process’s required outcome (the product’s drying in this case)? What is the effect of the number of products in the oven on this process, and the effect of the humidity of the product when it enters the oven? All these variables need to be tested. This is part of the process validation. Validation is done in producing a certain product, not of the machines.

It is possible to combine these processes into one. The validation engineer must determine whether this is possible or preferred. In this article, I have combined the equipment and the process validation.

Validation Plan

Before taking action, write down what you will do, why, your deliverables, and when you accept the outcome.

So we start with a validation plan. This plan includes purpose, scope, definitions, references, product and process description, product families, risk assessment, pre-requisites, acceptance criteria, requirements for re-validation, training, and the validation strategy. A risk assessment must be made (according to ISO 14971) for all process steps (please read this article for more information on risk management). Describe in the plan how you will handle these topics or, if still unknown, that it will be described in the summary reports.

product and process description

All the products under the validation are described in the product description, including references to materials and product specifications. When a family of products are defined to reduce the number of validations, the family is defined in the plan, including a justification of why this is acceptable and how the family is represented. Remember, validations are done in the process of producing a certain product.

The process is described to show clearly which process steps are part of the validation. A process flow is highly recommended.

Validation strategy and deliverables

The validation strategy is discussed in the plan. Which qualification steps are done per process step, combined, and which steps have 100% verification? Which deliverables (protocols, plans, summary reports, test cases etc.) are planned? For example, the OQ and PQ can be combined in one protocol, but separate summary reports are required.

When deviations are observed, the plan must contain how to handle these deviations. Some may be handled in the summary report, while others must follow the CAPA procedure. Finally, it is important to mention how producing a product or product family is monitored if a periodical evaluation of the validated state is required and when revalidation is necessary.

The validation plan might require updating during the validation process, so document revision history must be recorded. The document needs to be approved by the appropriate functions in the company before commencing with the validation.

Different validation plans can be written with a master validation plan covering all processes for extensive and complex processes.

Validation steps

Protocols

Before executing one of the following steps, protocols should be written. You must write a protocol for all steps (IQ, OQ, PQ, and Engineering study). However, it might be more efficient to combine some protocols. (IQ/OQ protocol for a machine or an IQ/OQ/PQ for a simple process).

The content of a protocol can be general information such as the objective, scope, definition, key responsibilities, and references. Further, the validation outline is given, which steps are described in this document (e.g. IQ/OQ/PQ) with rough details of what the validation step will contain, and pre-requisites and acceptance criteria are defined per step.

The details of each qualification test can be described in the protocol or test cases. These test cases describe what actions will be done and can be used to record the actions and the reporting. One way of designing a test case is making a table with the test step, expected result, actual result (which needs to be filled in during the actions), deviations between expected and actual result (Y/N), Pass/Fail, References (e.g. a test report), and initial and date of the tester per step.

The protocols and test cases need to be reviewed and approved by the appropriate functions in the company before starting the qualification. The document revision history needs to be recorded.

Installation Qualification (IQ)

All equipment that is used in a process needs to go through IQ. The following topics might be covered during IQ, but this list is not exhaustive.

• Is the equipment delivered complete (all parts, cables, hoses, spare parts etc.) and all utility present (gas, pressure, electricity etc. )?
• Are the equipment documentation present and complete (manuals, drawings, maintenance contract, etc., construction materials)?
• Are instructions present (cleaning, calibration, maintenance, start-up, stopping, operation). Often these instructions must be written by the company under their quality system.
• Do safety features function as expected (emergency stop, the functioning of safety fences, over-heating controls, recovery from electrical loss)
• Software validation (if the software is “off the shelf” coming with the machine (not adjusted by you or for you), then recording the software version might be enough.

Operational Qualification (OQ)

At Vosfox Medical, the OQ consists of three steps

1. Process development (needed to define the process parameters roughly). This step is necessary with new processes, but also with known processes, a limited process development might be needed.
2. Design of the experiment to understand the interaction between parameters and define the low, nominal and high settings for the verification run.
3. Verification run

one can choose to define a separate engineering study protocol or make it part of the operational qualification protocol. The engineering study is not an official step of the validation, but still vital to continue to the OQ.

An OQ test case is more difficult to describe generally, as the content depends on the process. Some of the following topics could be covered.

• Verification of prerequisites (e.g. successful execution of IQ and closing of all deviations, training of operators)
• During execution, the latest documentation revision (e.g. product specification, work instructions)  should be present, and the revision recorded.
• Process verification with high, nominal and low settings (for example) containing the following topics

1. Length of the test run
2. The lot number of used materials, the ID of equipment and the software
3. Batch-related information (date, time, lot number etc.
4. Proof that the process was stable before starting OQ sampling and record process setting
5. Collecting samples for quality control, proof sample plan executed correctly.
6. Record all production information (process parameters, batch records, QC results, etc.). Make references to print-outs, reports, records, photos, etc.).
7. Ensure equipment and tools are maintained and calibrated.

Performance Qualification (PQ)

The PPQ is a documented verification of all aspects of an individual process. Take the example of the four parts produced, assembled and packaged in the automated packaging line. The PQ verifies that the whole process line works according to expectations and is stable and reliable.

Depending on the risks, one to three PQ runs are required. For medical devices, normally, three PQ runs are done. This gives high confidence that the process is stable and reliable after successful PQ runs. However, you can divert from this (if it is documented with arguments in the validation plan).

The PQ test case can contain similar topics described in the OQ but usually only for the nominal settings. These are some other topics to consider

• The length of the PQ test run is one defined (commercial)batch.
• PQ products can be considered safe to sell as commercial products (if you have good reasons….).
• Pre-requisites are finished OQ run with no nonconformities open (or with an action plan).
• All work instructions, batch records, batch release forms, quality control forms etc., are final and activated (during OQ draft versions are acceptable).
• Product Specifications, Material Specifications, process setting sheets, and Quality Assurance Agreements (with a customer, for example) are all final and activated.

Summary reports

Then, summary reports must be written when all the work is done.

• For each validation-plan is, a validation summary report is required
• For each protocol, a protocol summary report is required

The validation summary report can contain the following information:

• General information such as purpose, scope, references (to change control forms, risk management reports etc.), roles and responsibilities
• Description of the validation activities
• Evidence of the training efforts and effect
• Deviations from protocol, failures, and nonconformities are listed and discussed (references to NC documentation and discussion of the risk hereof)
• Acceptance of the validation

The protocol summary report collects the most important information on the execution of the protocol. It usually contains the following information:

•  General information about the product or process, references, signature box
• Summary of the run(s) (length, no issues, Cpk values etc.)
• All fails, nonconformities or deviations of the protocol are collected and discussed process/product/patient/user/operator, the reason for deviation etc.).
•  Summary of validated process parameters
• Attachments (test cases with all attachments, for example)
•  Conclusion
• Revision history of the report.