Process Validation

Process validation is not the most exciting topic for engineers, but this is an important task for many engineers, especially in the Medtech or Pharma field.  Online there is a lot written on validation; you read about the DQ, IQ, OQ, and PQ. Often I asked my computer, ‘YES, BUT WHAT SHOULD I DO?” For start-up companies with limited knowledge and budget (hiring an expensive consultant is always possible), validation is a topic where Google doesn’t provide a concise answer. I will try to help you understand these validation steps better with this article. This article is about process validation. Test method validation, packaging/transportation or sterilization validation follow similar steps (IQ, OQ, PQ), but there are also differences.

Why bother?

Why do process validation? It is time-consuming and expensive. The producer must guarantee that the product fulfils the agreed specification when producing devices or components. The first until the ten millionth produced product. If you would test each product on all specifications, you would not need to validate the process. 100% verification is possible to check your products and is especially useful for low-volume production and non-destructive testing. The production process must be validated when 100% verification is not preferred. Validation provides us with the confidence (to a defined confidence level) that all produced products fulfil the defined specifications.

Or the less motivational speech: You have to!

Where to start?

Before validating a production process, you must define your product using 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 during the process.

Secondly, you need a production process. Maybe this process is not fully 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 the temperature is set 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 required outcome of the process (the drying of the product 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, you must 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.

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.

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 the process of 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 need to 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.

Engineering study

Now that the machine’s basic functions are working, an engineering study is needed to develop the operating windows. The engineering study is not an official step of the validation, but still vital to continue to the OQ. The engineering study contains, in general, the following steps.

  • Process development (Understand the underlying principles of the process)
  • Design of Experiment (DoE) (determine and quantify relationship settings and the response of process)
  • Process verification (boundary testing to verify extreme circumstances that may occur during regular production)
  • Process Optimization (run as efficiently as possible)

Not all four steps are required to do always. Maybe the process is known, and the process development can be skipped. Usually, the DoE and process verification should be done per product to define the operating windows. Process optimization may not be feasible or is no priority and therefore not done (or delayed).

It is also possible to combine the engineering study (because it is not an official part of validation) in the IQ and/or OQ. For example, the process development in a separate IQ test case and the DoE and Verification in an OQ test case (before running the regular OQ test case).

Operational Qualification (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)
  • Ensure that all nonconformities that happened during previous steps are closed or have approved action plans in place, and declare/explain why there is no impact on the OQ
  • Verify if all operators are trained (training records attached).
  • During execution, the latest revision of the product specification/drawing, material specifications of raw materials, FMEA, process setting sheet, and validated quality control methods (Gauge repeatability and reproducibility or GRR) 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 (e.g. one hour or 200 pieces)
  2. Lot number of raw materials or parts used in the process
  3. Batch number of products produced in this test (for traceability), date and time of the start of the batch
  4. Proof that the process was stable before starting OQ sampling
  5. Proof of correct software version.
  6. Collecting samples for quality control (e.g. metrology), proof sample plan executed correctly (including packaging and labelling of samples)
  7. Provide proof that the quality control is well executed and documented
  8. Gather all production (process parameters, batch records etc. and QC documentation (measuring reports) and attach these to the test case. If necessary, proof of the print-out of a machine is taken during the run. Ensure all documentation is dated and signed, and marked as an attachment.
  9. Ensure that the production machine, tools, or instruments used (e.g. in QC) are identified, maintained and calibrated.
  • In a separate test case, the risk mitigation actions can be verified. During the risk management process, likely a process-FMEA has been produced. The potential failures with high risk (product of severity, occurrence, and detectability) have defined risk mitigation actions. During OQ, the verification of these actions can be checked. After the OQ run(s), no intolerable and preferably no undesirable risks should remain.

Performance Qualification (PQ)

The PPQ is a documented verification of all aspects of an individual process. Take the example of the four parts being 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 (or not, 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.

About Sandra de Vos

Sandra de Vos has been working with (polymeric) medical devices for over 12 years. She has set up a Quality Management System (QMS) from scratch to ISO 13485 certification, which included product development (DHF file), Risk analysis and process development (process and product validation). She is a certified Lead Auditor.

Currently, she is the founder and CEO of Vosfox Medical. Vosfox Medical offers contract manufacturing services (CMO) for medical device companies.

Our CMO services include using our facilities and support to develop the production process and prepare it for clinical trials. We offer ISO Class 7 cleanroom, QA support, production process development and validation support, etc. We have several 3D printers in the cleanroom and produce medical-grade filaments (for FDM printing).

You can stay as involved as you wish and outsource what you want.

Please visit our website (vosfoxmedical.com), mail me (sandra.devos@vosfoxmedical.com), or call +31-650281838. You can also comment on the article and help me improve this and future articles.