ISO 13485 Rework

[MedtechQuality]

Hello,
I’m looking for input from ISO 13485 auditors or professionals with hands-on experience, particularly regarding rework.

ISO 13485 clause 8.3.4 states:
“The organization shall perform rework in accordance with documented procedures that take into account the potential adverse effect of the rework on the product. These procedures shall undergo the same review and approval as the original procedure.”

I find this requirement open to interpretation and would appreciate clarification on the following points:

1. In accordance with documented procedures
   Does this mean all rework must be derived from existing approved work instructions? In practice, there are situations where rework instructions are written step by step and are not directly based on any released procedure. Is this acceptable under ISO 13485?
2. Potential adverse effect
   How should potential adverse effects of rework be addressed? Is it expected that these risks are evaluated within existing risk management files, or is it acceptable for the rework instruction itself to include a risk assessment section describing the nature of the rework, any potential impact on product safety or performance, and confirmation that final quality control includes 100% verification?
3. Same review and approval as the original procedure
   If rework is based on an existing work instruction that required approval from multiple functions, must the same functions approve the rework instruction?
   Additionally, for rework instructions that are not derived from an existing work instruction, how should “same review and approval” be interpreted? Would approval in accordance with an NCMR SOP that defines required approvers be sufficient?

Thank you in advance for your insights.

 

[Bev D]

In accordance with documented procedures
Does this mean all rework must be derived from existing approved work instructions? In practice, there are situations where rework instructions are written step by step and are not directly based on any released procedure. Is this acceptable under ISO 13485

These may have been previously documented. Some rework is so common that it makes sense to write out rework procedures. Uncommon rework is to be documented with a NEW work instruction. It is that simple. The intent is that operators not follow verbal instructions for rework.

Potential Adverse Effect
Since rework is typically done after the fact where there might be ‘things in the way’ and it includes undoing things (as opposed to simply doing things) a risk assessment is absolutely the right thing to do. There will be new actions that you haven’t taken into consideration in your original assessment. One of the questions I would ask here is why wouldn’t you do this? In my organizations I have required a new (but much smaller) ‘fmea’ type risk assessment and it saved our patooties many many times.

Same review and approval as the original? Yes the same functions need to review and approve if the rework is based on an original instruction - this only makes sense. See potential adverse effects response. In theory the original reviewers were experts in the actions recorded by the original instructions so why wouldn’t they also be the experts for the rework? And the same holds for original rework instructions - any action that touches or effects the original tasks should be reviewed and approved by the experts. Again why wouldn’t you do this?

Rework is often inherently more ‘risky’ than the original work as it is not practiced and does things that may not have been qualified in the first place….

 

[Tidge]

I can share one set of experiences I've had that can perhaps illuminate the point by @Bev D regarding common/uncommon rework, from a low-volume medical device manufacturer.

Typically, there was no such thing as "common" (i.e. proceduralized) rework. If there was a non-conformance it was most common that the device got "broken down" to its conforming subassemblies and then reassembled (with investigation, etc. etc.) and found to be conforming via standard existing procedures prior to release. Risk assessments were addressed within the NCR process, referencing appropriate information in the existing risk management files. This is pretty ad hoc of course, but many nonconformances that can be addressed through rework are singleton one-offs. Some of course rise to Corrective Actions.

That same company did acquire a product that had (in my words) "rework baked into the design" due to variability inherent to the design that the executive management (via the engineering team) couldn't/wouldn't address... and the design wasn't inexpensive enough to be able scrap devices that would fall outside of required performance characteristics. That device had a "rework" element baked into the approved procedure to allow for the try-try-again aspect of the design.

There was some internal debate if the latter was truly considered "rework" because this procedure didn't start with a released product. I'll say that I was on the side that didn't like that finished goods in the same lot may have gone through wildly different assembly processes and allowing for that variability within a single procedure in the DMR was papering over a design defect that could have been addressed.

 

[MedtechQuality]

@Bev D @Tidge

Thank you for your input. Here is my further clarification

1. If there is a case where rework instructions are written step by step and are not directly based on any released procedure, is it acceptable to perform the risk assessment within the rework instruction itself, without formally referencing the existing risk management files, when the specific rework scenario is not covered in those files? In this approach, the rework instruction would document the potential risks introduced by the rework, describe the risk controls, and confirm that the rework does not adversely affect the final product outcome, for example, through 100 percent final quality control verification or a simple component replacement, such as replacing a 7.5 Fr component with a 7 Fr component, followed by full inspection. Would this be considered compliant with ISO 13485 clause 8.3.4, assuming the rework instruction is properly reviewed and approved?

2. With respect to the requirement for the same review and approval as the original procedure, consider a case where a rework instruction references an existing procedure that was originally approved by R&D, Design Quality, Marketing, Engineering, Operations, and Purchasing. The nonconformance in this case is that a 7 Fr component was installed instead of a 7.5 Fr component, and the rework involves removing the 7.5 Fr component and retaining the 7 Fr component. In this situation, what is the value of requiring approval from functions such as R&D or Marketing? R&D is one of the most valuable and limited resources in the organization, and involving them in the approval of a simple, low-risk rework does not appear to add meaningful value or improve product safety or performance. Is it acceptable to define rework approval based on relevance and risk, rather than requiring all original approving functions to review every rework instruction, provided that the approval process is justified, documented, and aligned with the scope and impact of the rework? Is it compliant with ISO 13485?

 

[Tidge]

1. If there is a case where rework instructions are written step by step and are not directly based on any released procedure, is it acceptable to perform the risk assessment within the rework instruction itself, without formally referencing the existing risk management files, when the specific rework scenario is not covered in those files?

IMO, this is bordering on an organization not adequately addressing concerns about the potential risks to patients in a consistent manner. "instructions" really don't demonstrate that risks are being considered; typically manufacturing risk instructions get accounted for in the RMF. Put another way... who in "R&D, Design Quality, Marketing, Engineering, Operations, and Purchasing" is going to speak to the clinical risks to patients?

2. With respect to the requirement for the same review and approval as the original procedure, consider a case where a rework instruction references an existing procedure that was originally approved by R&D, Design Quality, Marketing, Engineering, Operations, and Purchasing. The nonconformance in this case is that a 7 Fr component was installed instead of a 7.5 Fr component, and the rework involves removing the 7.5 Fr component and retaining the 7 Fr component. In this situation, what is the value of requiring approval from functions such as R&D or Marketing? R&D is one of the most valuable and limited resources in the organization, and involving them in the approval of a simple, low-risk rework does not appear to add meaningful value or improve product safety or performance.

Manufacturing didn't build the device the way R&D intended it to be built... so why are you proposing building it a different way (via rework) without involving R&D? If an appropriate reviewer's is time is more valuable than the nonconforming materials that would otherwise be scrapped, then scrap the materials. In this case as described... a "too big" part was installed instead of the correct sized part. Setting aside engineering questions of "how could this be allowed to happen?" it seems to me that Engineering needs to be consulted about what the potential consequences of having the wrong sized part installed originally might be.

 

[Bev D]

^ What @Tidge said ^ I’ll add that maybe you have too many signatures? Why would Marketing sign off on a production work instruction? And why would purchasing sign off on a production work instruction? I can absolutely see that R&D should sign off on the original and most revisions.

What is design quality? Do you not have a separate quality engineering function for production/post development activity?

Typically a risk assessment is a separate document and R&D should certainly be involved in that. Putting it in the rework instruction is OK I guess but it really mixes two separate activities with two separate types of personnel in one document. It isn’t really a time saver…

You are always better off over assessing than under assessing. Believe me production is going to be super biased to not do any risk assessment, document the rework instructions or gain review and approval. The only thing they will care about is volume…

So this leads to me to ask: what is your REAL concern? What is prompting you to ask about all of this? The requirement is painfully clear…so there must be some unspoken thing going on…truly the real effort should be focused on the causal mechanism of the defect that requires rework - that is valuable. Contract lawyering the requirement is not.

Oh and by the way, production’s time is just as valuable as R&D’s time. After all if no one is making the product to sell what difference does it make if R&D made a brilliant design?

 

[Jean_B]

Instead of adding a diatribe to well made points by Tidge and Bev; seperate things of value.

• If you do do the risk management in the rework instruction, it needs to be cross-referenced with the batch(es) it affects. I.e. on the rework instruction it mentions to which batch it applies, and within the DHR of the batch it must be clear that rework took place and which it was. It must also always consider the existing up-to-date risk management, and should be up-to-date with post-market surveillance data.
  • In advanced QMS setups you might see common occurring defects receive 'default' rework instructions: if the NC has certain (necessary and sufficient) characteristics and no unusual further aspects a pre-approved rework can be applied. This needs further work on how you deal with traceability though, as the rework can no longer contain the batch number to which it applies. These usually are tied into the Risk Management File, specifically pFMEA's/Control Plans, and a defect library of some sort.
• Iterative production steps (polish until... / tighten until...) is not rework in the traditional sense, though allowing this structure in your instructions depends on whether things can be overdone (without undo) or underdone (with difficult redo/without undo) and whether the impact and effort expended is negligible elsewhere.
• Rework has it meet original specifications ; repair has it meet requirements. This means rework cannot deviate from targeting original specifications, though a deeper and broader reasoned judgment may apply the repair philosophy together with release under concession. Though applying repair before it was ever sold is odd, technically nothing prevents it. But releasing things under concession is something to be signaled up the chain regardless as it can be the first signal for myriad of bad things having occurred or going to occur.

 

[Bev D]

When I was in Aerospace (Aircraft engines) repair prior to shipment was not common but not rare. We did need - and always got - prior review and approval from the Customer. A typical repair was to ‘add’ metal to a part that was cut too small and then to re-machine it to the correct size.

 

[Tidge]

When I was in Aerospace (Aircraft engines) repair prior to shipment was not common but not rare. We did need - and always got - prior review and approval from the Customer. A typical repair was to ‘add’ metal to a part that was cut too small and then to re-machine it to the correct size.

This makes sense to me.

In the regulated medical device industry there is always the specter of "adulterated product" and practices leading to the release of adulterated product. I'm not passing judgement on the potential final outcomes (that's why a risk analysis exists) but I'd think a regulated MD manufacturer would go out of their way to avoid such an outcome at all costs.

 

[Bev D]

The thing I am always suspect of is risk assessments that are pencil whipped simply to ‘meet’ the requirement. When someone starts questioning the documentation of or need for a risk assessment, review & approval, I suspect that the risk assessment is a pencil whipping exercise. These are obviously a waste of time and those who must participate will balk at it. I had an Engineering director once who got upset with my requirement for development FMEAs - his only retort was that the product support and manufacturing engineers “had better read them” as he didn’t want his engineers wasting their time…how useful do you think those things were?