Medtech starters, do you have more questions than answers on Quality Assurance topics, read my blogs and see if this helps out a little. Reading might be boring (I already start yawning), but it is vital for your company’s success. In my first start-up company, Medisse, one of my activities was to take care of quality assurance and regulatory issues. But new to this, it took me a lot of time to get to know the world of Quality Assurance. It is always possible to hire expensive consultants, but I learned that they are not motivated to tell you efficiently what you need to know. In this way, they can bill more hours. Online there is a lot written on these topics (e.g. Design History File, CAPA process or Process Validation), but usually at a high level. Often I asked my computer, ‘YES, BUT HOW?” For start-up companies with limited knowledge and limited budget, this is a real issue where Google doesn’t provide a concise answer (this is what Wikipedia says about process validation). In this and other articles that I will write, I will help you understand these processes better. In this article, I explain PROCESS VALIDATION. Please let me know if I succeeded by leaving comments.
When producing products (this could be medical devices or parts thereof) the producer needs to guarantee that the produced product is fulfilling the set specification. This is valid not only for the first product but also the 1 millionth product that is produced. If you would test every single of these million products, you don’t need validation, you are doing Verification, which is allowed. You verify that all products fulfill their specification. As this is often not practical and too expensive, we want to validate the process so we can 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 that are 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 are going to do, why, what are your deliverables and when do you accept the outcome.
So you need to start 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 here what the intentions are 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 also different processes that are linked to each other and different (intermediate) products or one set of equipment for different products. An example of a process to validated are 4 different parts produced, to be assembled to 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 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.
For very large and complex processes different validation plans can be written with a master validation plan covering all process.
Before executing one of the following steps protocols should be written. You have to 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 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 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 in test cases. These test cases describe in detail what actions will be done and can be used for the recording of the actions and the reporting as well. 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 and 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 part, cables, hoses, spare parts etc. are present.
- Is the equipment documentation present and complete (manual, drawings, maintenance contract etc. materials of construction)?
- 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) than recording the software version might be enough.
Now you know that the machine 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 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 be not 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 as 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 is depending on the process. Some of the following topics could be covered.
- Verification of prerequisites (e.g. successful execution of IQ)
- Ensure that all nonconformities happened during previous steps are closed or have approved action plans in place and declare/explain why this there is no impact om 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 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 labeling 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 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 a 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 as 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 of 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, that 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 the use of our facilities and support to develop the production process and make it ready 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.
For more information please visit our website (Vosfoxmedical.com), mail me (firstname.lastname@example.org), or call +31-650281838. You can also comment on the article and help me improve this and future articles.