Solving Problems Amid Auditing Process ValidationsSolving Problems Amid Auditing Process Validations
Teresa Cherry, VP of quality and regulatory affairs at Xenix Medical, discusses what to look for in auditing process validations and how to mitigate problems before they arise.
October 5, 2023
Process validations are crucial when assessing and mitigating risks associated with manufactured medical devices. Basic steps can also be taken to improve problem-solving and root cause analysis.
To address these concerns, Teresa Cherry, BSME, MSE, CMDA, CQE, CQA, RAC Devices, who is vice president of quality and regulatory affairs at Xenix Medical, will give two presentations at October’s Medical Design & Manufacturing (MD&M) Minneapolis show: “Auditing Process Validations – What to Look For” and “Problems with Problems – How Can We Get Better?”
When are process validations needed?
Cherry: Based on guidance from the International Medical Device Regulators Forum (IMDRF), previously the Global Harmonization Task Force (GHTF), process validations are needed when the outcome of the process cannot be verified/inspected, is not cost-effective to perform verification/inspection, or the outcome is not being verified/inspected.
Assess whether a process validation is needed or should be documented in the manufacturer's quality management system. If it is determined that a process validation is not required, the justification for not performing should be included in the documentation.
What are the major items of an audit checklist for process validations?
Cherry: Some of the many critical items to include on an audit checklist are:
Do the process parameters documented in the process validation align with the parameters for the current process as documented in the work instruction? I've audited several processes and their respective validations where the current process parameters are outside of what was validated, with no supporting documentation provided.
Was calibration for the inspection equipment/instrumentation that was used for the validation testing current and within tolerance? I audited a supplier who did not use a calibrated instrument for measurements taken for acceptance of the validation testing activities. This happens more frequently when the engineering department performs the validation with its "Engineering Use Only" equipment.
Does the process validation protocol include a clear statement of the scope and methods? I always tell attendees to write documents knowing that someone outside their organization — like FDA or a Notified Body — will be the reader and to ensure that it tells the full story.
Does the process validation protocol include a documented valid statistical rationale for the sample size? Was the defined sample size actually tested and documented in the report? I've seen where a protocol calls for a minimum of 59 test pieces and only 30 are tested, with no rationale provided in the report.
As with all auditing, the details should be confirmed as being consistent. Also, follow any audit trails to see where it leads you.
How can quality system documentation be improved for problem-solving?
Cherry: Because we are very busy as quality professionals, we will not remember in six months all of the details of the problem and how it was solved. This is especially true for documenting the root cause analysis and investigation results.
ALL details of the investigation should be documented, including any dead ends. If testing to determine root cause does not lead to confirmation, document it anyway. That way, if the problem recurs, we are not repeating testing that ends in a dead end again; plus, you get credit for the work that was performed during investigation activities.
Use your quality tools in your toolbox: Pareto Analysis, Fishbone (Ishikawa) Diagrams, Is-Is Not, 5 Why Tree/Matrix, Process Mapping, etc. These tools are so useful. However, we sometimes forget to use them all, relying instead on using our default “5 Why” for everything.
What basic steps can be taken to improve problem-solving?
Cherry: The methodology of Six Sigma defines the basic steps well — define, measure, analyze, improve, and control (DMAIC) — with the key step being the D: define. When the problem is well defined, it makes problem-solving so much easier.
When defining the problem, include a clear scope and any related details, such as part number, lot number, quantity affected, supplier/customer, date(s), equipment ID, process and process step, and how the problem was identified.
Once the problem is clearly defined, a thorough investigation can begin. Risk analysis should always be incorporated to ensure that the depth of the investigation is appropriate, and the due dates are prioritized accordingly. Lower risk problems that are not urgent can be set aside until the higher risk problems have been addressed.
About the Author(s)
You May Also Like