100% verification of special processes & risk based process validation?
- Thread starter jakeinquality
- Start date
The answer is going to be "it depends", because ultimately a regulatory authority is going to make that call. The challenge of course will be to have cleared the bar before they review it. What follows is my experience for medical device manufacturing, and I'm only going to be referring to process validation, not design validation, test method validation, software validation, etc. I can speak a little to pharma, but for what follows I'm only thinking about medical device manufacturing.
At zeroth order: The QMS must have an established plan to address process validations. There must be some guidance on how to handle process validations in a uniform manner. These are what are required.
There can be crummy plans, and there can be plans on a spectrum of robustness. Without a general plan, or evidence that one is being followed, that's a finding... even if there is some evidence that individual processes may have been validated (robustly or not).
At first order: *if* the manufacturer has a process that is *obviously* related to patient safety (sterilization, heat-sealing pouches for sterile products) such that someone with no knowledge of the risk management profile would recognize as potentially risky... it is *highly likely* that an auditor will review the Master Validation Plan (a typical output of the QMS requirement) to look for those processes, and then pick one to review. (The company is expected to have validated ALL of these process, per guidances).
We can debate (external, internally) which manufacturing processes must be validated, but there are a handful of classic manufacturing processes that fall into this "no-brainer" category. Presumably if a medical device was doing a good job with risk analysis, the company's own RM efforts would reveal these to be "must validate" as well. Risk Analysis is the lever to use to determine how robust a validation needs to be for any given manufacturing process(*1)... and if one needs to be done at all. Personal perspective: Any reduction in risk because of the implementation of a process must have complimentary OE that the claimed reduction is appropriate. See many discussions elsewhere about "powers of ten" used in quantitative ordinal FMEA values.
This review will be mostly to see if the validation followed the internal guidance for process validations with a little bit of "technical" questions. I use quotes around "technical" because there might be an auditor with some specific knowledge of that type of process, or remember other similar efforts from somewhere else, but it is more likely the auditor will simply ask something off the top of their head, like "Why didn't you do _____?" where the blank will be some sort of challenge they just thought up.
In my experience, auditors never really dig into most methods of process validation... even when an auditor happens to recognize that the company may not be using an industry standard approach. The questions from auditors are more like: "How did you choose this?"... basically questions to see how red faces become.
At higher orders: a process validation is most likely to get auditor scrutiny via a review of complaints and/or non-conformances related to products. Most auditors I've known have done a little bit of repeating "root cause analysis"... it's just the way humans are wired. So if they are aware of a particular process used in manufacturing a product that could be implicated, they might ask for details (and compare what was done against the QMS plans and policies). If the process itself was previously implicated in the complaint/NC, that might get deeper review.
(*1) I could write more about the translation of design requirements into manufacturing process requirements, but all I feel like writing now is this: don't repeat design verification on the manufacturing floor.
At zeroth order: The QMS must have an established plan to address process validations. There must be some guidance on how to handle process validations in a uniform manner. These are what are required.
There can be crummy plans, and there can be plans on a spectrum of robustness. Without a general plan, or evidence that one is being followed, that's a finding... even if there is some evidence that individual processes may have been validated (robustly or not).
At first order: *if* the manufacturer has a process that is *obviously* related to patient safety (sterilization, heat-sealing pouches for sterile products) such that someone with no knowledge of the risk management profile would recognize as potentially risky... it is *highly likely* that an auditor will review the Master Validation Plan (a typical output of the QMS requirement) to look for those processes, and then pick one to review. (The company is expected to have validated ALL of these process, per guidances).
We can debate (external, internally) which manufacturing processes must be validated, but there are a handful of classic manufacturing processes that fall into this "no-brainer" category. Presumably if a medical device was doing a good job with risk analysis, the company's own RM efforts would reveal these to be "must validate" as well. Risk Analysis is the lever to use to determine how robust a validation needs to be for any given manufacturing process(*1)... and if one needs to be done at all. Personal perspective: Any reduction in risk because of the implementation of a process must have complimentary OE that the claimed reduction is appropriate. See many discussions elsewhere about "powers of ten" used in quantitative ordinal FMEA values.
This review will be mostly to see if the validation followed the internal guidance for process validations with a little bit of "technical" questions. I use quotes around "technical" because there might be an auditor with some specific knowledge of that type of process, or remember other similar efforts from somewhere else, but it is more likely the auditor will simply ask something off the top of their head, like "Why didn't you do _____?" where the blank will be some sort of challenge they just thought up.
In my experience, auditors never really dig into most methods of process validation... even when an auditor happens to recognize that the company may not be using an industry standard approach. The questions from auditors are more like: "How did you choose this?"... basically questions to see how red faces become.
At higher orders: a process validation is most likely to get auditor scrutiny via a review of complaints and/or non-conformances related to products. Most auditors I've known have done a little bit of repeating "root cause analysis"... it's just the way humans are wired. So if they are aware of a particular process used in manufacturing a product that could be implicated, they might ask for details (and compare what was done against the QMS plans and policies). If the process itself was previously implicated in the complaint/NC, that might get deeper review.
(*1) I could write more about the translation of design requirements into manufacturing process requirements, but all I feel like writing now is this: don't repeat design verification on the manufacturing floor.
More’s the shame. How sad. There are too many weak auditors who don’t know hte standard and too many that impose their own ignorant beliefs. This only feeds the ignorant non-value add actions to appease the bully auditor and weasle actions to get around the weak un-knowledgable auditor. Neither do anything to improve quality. The standard should be clear (withstand a plain text reading) and/or the company should simply do the right thing.
I respectfully disagree. We can debate about anything that interests us. If it was completely unrelated I'd support "move it to a separate thread"; but it isn't.
Let me please play devil's advocate:
Suppose an output can (= does not qualify for "cannot") be verified, but is in fact NOT BEING verified. How is that okay for providing confidence? How/why should that exempt from other means of gaining confidence, e.g. process validation?
It's a case I'd vote for looking for the intent rather than reading literalistically. I know that "looking for the intent" is a slippery slope; that's why I don't usually do that. But there are some cases it makes sense. I agree that context matters. I am making those statements from a specific context. It doesn't necessarily apply in all caese and all industries.
Suppose an output can (= does not qualify for "cannot") be verified, but is in fact NOT BEING verified. How is that okay for providing confidence? How/why should that exempt from other means of gaining confidence, e.g. process validation?
It's a case I'd vote for looking for the intent rather than reading literalistically. I know that "looking for the intent" is a slippery slope; that's why I don't usually do that. But there are some cases it makes sense. I agree that context matters. I am making those statements from a specific context. It doesn't necessarily apply in all caese and all industries.
The right thing by what/who? Many times doing right by the shareholders is not the same as doing right by the patient.
There is also a big difference between an opaque ad hoc interpretation by an ignorant individual, and a cumulative interpretation by many non-ignorant professionals over many years and countless devices / technologies / cases. The breakdown in this case is that this interpretation wasn't integrated back in a revised standard / regulation. I suspect this is not incidental. It would have set in ink a more onerous obligation on manufacturers.
Entering the conversation with the Devil's legal representative: I *felt* that at my longtime manufacturer that there was a very poor (cloudy) process of transferring designs to production. When I was on the manufacturing floor I worked really hard on formal reviews (with all stakeholders, informed by the DHF) to identify specific production requirements and the make sure that the necessary manufacturing specifications were either verified or the process of achieving those was validated.
That company never quite got out of the mode that each device they built ought to be subjected to a repeat of design verification, but for a few years I was able to break that mode of thinking. I credit my doggedness; but those efforts were received as not just no-value-added, but others who did less were seen as "better" engineers for not bothering stakeholders, etc. The eventual consent decree was pretty eye-opening; the authorities wanted to know why only a fraction of the validation efforts made any sense.
That company never quite got out of the mode that each device they built ought to be subjected to a repeat of design verification, but for a few years I was able to break that mode of thinking. I credit my doggedness; but those efforts were received as not just no-value-added, but others who did less were seen as "better" engineers for not bothering stakeholders, etc. The eventual consent decree was pretty eye-opening; the authorities wanted to know why only a fraction of the validation efforts made any sense.
In fairness, if your device is a big, complex, multidisciplinary piece of equipment that is only made in a low unit count (e.g. MRI machine) maybe it makes sense to have a version of "design verification" as a release activity. Of course when serial production is considered it's an illogical redundancy.
Design Transfer is often a weak point. People tend to think of it as "a point", a literal handover, not as a stage or an activity. Maybe it's because it's typically the watershed between R&D/Engineering and Manufacturing. When I was (product) Design Engineering manager I took delight in taking ownership of that stage, together with my partners from "the other side of the wall". It was a push AND pull effort, not just a pull (as is typically the case - sounds like what you described), or just a push (which in my experience is very rare). The results were very good. We all realised it pays off very well later on, in routine manufacturing.
I agree completely. We had an all-too-brief period with relatively smooth production with relatively little fallout (in production) and complaints (from customers).
The most discouraging part of my post-manufacturing-floor experience was during part of the consent decree fact-finding. One auditor wanted to know the reason for a specific test in manufacturing, and the new product development head didn't know the reason, but also didn't think to consult with manufacturing because he was one of those "solid wall between development and manufacturing types". He ended up embarrassing himself, not knowing how the test parameters were established (all detailed in the validation documentation) and decreed that the test would be gotten rid of... along with all sorts of other crazy promises to the auditor. The test was pulled "because promise", and we started having fallout again... plus all the other crazy work he put the company on the hook for.
The traditional starting spot is the 21 CFR 820 QSR Pre-amble:
"iii. Process Validation (§ 820.75)143.
We can turn to how it is inspected at the authoritative source: Page 9
It opens with "The QS/GMP does not require the validation of all manufacturing processes. Before inspecting a manufacturing process for process validation, it is important to determine if the results of the process cannot be fully verified by subsequent inspection and test. The lack of a subsequent inspection and test should be stated in the EIR along with any process validation issues."
and has
"All operators should be qualified for their work, but because the results of validated processes need not be fully verified, the need for qualified operators is especially important to assure that validated processes are properly conducted and controlled and produce results or products that meet specifications."
and
"As noted above, QS/GMP regulations do not require all medical device manufacturing processes to be validated Per 21 CFR 820.75. However, where the results of a process cannot be fully verified by subsequent inspection and test, the process shall be validated."
It stays stuck at 'can'.
FDA (in their presentation "Quality System RegulationProcess Validation" of 2015: https://www.fda.gov/media/94074/download) also refers to GHTF guidance: https://www.imdrf.org/sites/default...g3-n99-10-2004-qms-process-guidance-04010.pdf
"Each process should have a specification describing both the process parameters and the output desired. The manufacturer should consider whether the output can be verified by subsequent monitoring or measurement (A). If the answer is positive, then the consideration should be made as to whether or not verification alone is sufficient to eliminate unacceptable risk and is a cost effective solution (B). If yes, the output should be verified and the process should be appropriately controlled (C)."
and "If the output of the process is not verifiable then the decision should be to validate the process (D); alternatively, it may become apparent that the product or process should be redesigned to reduce variation and improve the product or process (E). Also, a change in a manufacturing process may result in the need for process validation even though the process formerly only required verification and control.The risk or cost may also be reduced by redesigning the product or process to a point where simple verification is an acceptable decision (E)"
The letters in this text of the public guidance refer to parts of a flowchart:
That seems to imply that if you do not end the flow with a verification action, you can only end it in a validation activity (or run through redesign).
It would also be the sensical thing.
That means the actual filter would happen on is the process output relevant to control (whether through verification or validation), which is arrived at through specifications, which you are free to define (in line with the system you have for it). However, specifications can state what needs inspection (bubble/balloon) as an instruction, but showing whether it requires control at the validation level isn't so widely 'standardized'. It usually focuses on tolerances to be achieved, but there's no unique commonly known symbols that differentiates that it must be validated because it can't or isn't verified. The reasons for highlighting such a part of a specification should usually trace back to them being relevant to ensure or assure safety and effectiveness.
"iii. Process Validation (§ 820.75)143.
- A few comments on proposed§ 820.75 Special processes stated that the meaning of the term ‘‘special processes’’ was unclear. Other comments stated that FDA should provide examples of processes that would be considered ‘‘special processes.’’
- Several comments stated the term ‘‘fully verified’’ was unclear and should be deleted.
- In response to the comments, the term‘‘special processes’’ has been dropped from the regulation and the term ‘‘process validation’’ is defined in§ 820.3(z)(1).
- The section now requires that when a process ‘‘cannot be fully verified by subsequent inspection and test, the process shall be validated with a high degree of assurance. * * *’ ’Examples of such processes include sterilization, aseptic processing, injection molding, and welding, among others.
- The validation method must ensure that predetermined specifications are consistently met.
- The new § 820.75, entitled ‘‘Process validation,’’ is consistent with ISO9001:1994, section 4.9, including the terminology ‘‘fully verified.’’ FDA does not believe this terminology is unclear since it has been used in ISO 9001:1987 and 1994 and explained in several guidance documents."
We can turn to how it is inspected at the authoritative source: Page 9
It opens with "The QS/GMP does not require the validation of all manufacturing processes. Before inspecting a manufacturing process for process validation, it is important to determine if the results of the process cannot be fully verified by subsequent inspection and test. The lack of a subsequent inspection and test should be stated in the EIR along with any process validation issues."
and has
"All operators should be qualified for their work, but because the results of validated processes need not be fully verified, the need for qualified operators is especially important to assure that validated processes are properly conducted and controlled and produce results or products that meet specifications."
and
"As noted above, QS/GMP regulations do not require all medical device manufacturing processes to be validated Per 21 CFR 820.75. However, where the results of a process cannot be fully verified by subsequent inspection and test, the process shall be validated."
It stays stuck at 'can'.
FDA (in their presentation "Quality System RegulationProcess Validation" of 2015: https://www.fda.gov/media/94074/download) also refers to GHTF guidance: https://www.imdrf.org/sites/default...g3-n99-10-2004-qms-process-guidance-04010.pdf
"Each process should have a specification describing both the process parameters and the output desired. The manufacturer should consider whether the output can be verified by subsequent monitoring or measurement (A). If the answer is positive, then the consideration should be made as to whether or not verification alone is sufficient to eliminate unacceptable risk and is a cost effective solution (B). If yes, the output should be verified and the process should be appropriately controlled (C)."
and "If the output of the process is not verifiable then the decision should be to validate the process (D); alternatively, it may become apparent that the product or process should be redesigned to reduce variation and improve the product or process (E). Also, a change in a manufacturing process may result in the need for process validation even though the process formerly only required verification and control.The risk or cost may also be reduced by redesigning the product or process to a point where simple verification is an acceptable decision (E)"
The letters in this text of the public guidance refer to parts of a flowchart:
That seems to imply that if you do not end the flow with a verification action, you can only end it in a validation activity (or run through redesign).
It would also be the sensical thing.
That means the actual filter would happen on is the process output relevant to control (whether through verification or validation), which is arrived at through specifications, which you are free to define (in line with the system you have for it). However, specifications can state what needs inspection (bubble/balloon) as an instruction, but showing whether it requires control at the validation level isn't so widely 'standardized'. It usually focuses on tolerances to be achieved, but there's no unique commonly known symbols that differentiates that it must be validated because it can't or isn't verified. The reasons for highlighting such a part of a specification should usually trace back to them being relevant to ensure or assure safety and effectiveness.