When producing products (this could be medical devices or parts thereof), the producer must guarantee that the produced product fulfils the set specification. This is valid not only for the first product but also for the 1 millionth produced product. If you would test every single of these million products, you don’t need validation, and you are doing Verification, which is allowed. You verify that all products fulfil their specification. As this is often not practical and too expensive, we want to validate the process to trust that the first and the millionth product are within specification.
The less motivational speech: its obligatory
Where to start?
Before you can validate a process, you need a product and a process to make that product. So first, you develop a product with a controlled process (Design Control). As an output of this design process, a product specification can be drafted. A product specification contains all information about the product, the production, the quality control, sampling, raw materials, sterilization, packaging, storage, etc. You don’t need all information ready when starting the validation process; this can be decided during the process. However, specifications needed before commencing validation are usually functional, material, dimensional, and mechanical.
Secondly, you need a production process. Maybe this process is not running completely stable yet, but that can be fixed in the Engineering Study. You can start.
Before taking any action, you need to write down what you will do, why, what your deliverables are, and when you accept the outcome.
So it would be best if you started writing a validation plan. This plan includes general paragraphs as purpose, scope, definitions, and references. One paragraph must be dedicated to risk assessment. From any process, a risk assessment must be made (according to ISO 14971). While writing the validation plan, the risk assessment might not have been done or finished, but write the intentions and refer to the documentation (e.g. risk management plan).
The following paragraph contains a short description of the site, process, and product to define accurately what needs to be validated. This can be one process and one product, but different processes linked to each other and different (intermediate) products or one set of equipment for different products. An example of a process to validate is 4 different parts produced, assembled into one product and packaged. The 4 parts are produced in 4 different machines (all 4 need to be validated); the assembly machine and the (automated) packaging machine all need validation. For example, an IQ, OQ for each machine and a PQ for the whole process. Other choices are also possible.
The equipment, the products and the processes that will be validated are clearly described in the validation plan. All the validation steps also need to be described.
Further, the plan should describe how to deal with raw materials, sampling, specifications and acceptance criteria. You can also describe what the validation deliverables are (which documents will be delivered). Finally, something needs to be written about the maintenance of the validated state. However, it is also possible to have this documented in procedures instead of a validation plan.
The validation plan might require updating during the validation process, and therefore 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.
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, 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 test step, expected result, actual result (which need 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. are present?
- 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.
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 done. 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, validated quality control methods (Gauge repeatability and reproducibility or GRR) should be present and revision recorded.
- Process verification with high, nominal and low settings (for example) containing the following topics
- Length of the test run (e.g. one hour, or 200 pieces)
- Lot numbers of raw materials or parts used in the process
- Batch number of products produced in this test (for traceability), date and time of the start of the batch
- Proof that the process was stable before starting OQ sampling
- Proof of correct software version.
- Collecting samples for quality control (e.g. metrology), proof sample plan executed correctly (including packaging and labelling of samples)
- Provide proof that the quality control is well executed and documented
- Gather all production (process parameters used, batch records etc. and QC documentation (measuring reports) and attach these to the test case. If necessary, proof the print-out of a machine is taken during the run. Ensure all documentation are dated and signed, and marked as an attachment.
- 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. Taking the example of the 4 parts being produced, assembled and packaged in the automated packaging line. The PQ verifies that the whole process line is working according to expectation 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 after successful PQ runs, the process is stable and reliable. 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, Quality Assurance Agreement (with a customer, for example) are all final and activated.
Then, when all the work is done, summary reports must be written.
- For each validation-plan is, a validation summary report is required
- For each protocol is 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 product or process, references, signature box
- Summary of the run(s) (length, with 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)
- Revision history of the report.
About Sandra de Vos
Sandra de Vos has been working with (polymeric) medical devices for over 12 years now. 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 consulting services and 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 we 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 (email@example.com), or call +31-650281838. You can also comment on the article and help me improve this and future articles.