Contract Manufacturers and MDF Responsibilities, ISO 13485:2016, Clause 4.2.3

Morlock

Involved In Discussions
Good day all. I posted this as a piggyback comment in a separate thread, but figured it might get more visibility as a standalone thread, so here we go:

I work for a contract medical device component manufacturer. During a recent ISO 13485:2016 surveillance audit, we got dinged for not having an MDF for each component that we process, with the intent being an MDF would allow us to more effectively apply risk management to the finished device, within the scope of our responsibility within the product lifecycle as a whole (i.e. "different risks or processing controls for Class 1 versus Class 3 devices" was the example offered by the auditor). We claimed N/A to Clause 4.2.3 during our initial re-certification audit last year, and this was deemed acceptable by the auditor then. This time, it wasn't... I've been told that, technically, we can't "N/A" anything not within Clauses 6, 7, or 8.

Is it the interpretation of ISO 13485:2016, Clause 4.2.3 that we, as a contract component manufacturer, have to hold the entire MDF (presumably sourced from our clients) for their finished devices, or are we to create an MDF that only reflects the scope of the component we service (perhaps something along the lines of a MDF/DHR hybrid)? I requested "one or more files either containing or referencing documents including" clause 4.2.3.a-f, and am getting quite a bit of pushback from our clients, who are reluctant to send over this information, and claim that it is THEIR responsibility to maintain this, not ours. How do I mitigate this? If our clients refuse, what options do we have so that we're still in compliance?

Thanks all.
 

Ronen E

Problem Solver
Moderator
I've been told that, technically, we can't "N/A" anything not within Clauses 6, 7, or 8.
That is true.

or are we to create an MDF that only reflects the scope of the component we service
That's the way to go.

There's no added value (for anyone IMO) in you pulling info upstream from your clients. I mean that in the way of formal documentation and presentation under 4.2.3; there is of course value in you thoroughly understanding your "User Needs" (7.3), but that's a different story.
There's some value in you letting information downstream into THEIR files, so upon audit a more complete picture may emerge. It might be a good marketing practice, but likely needs to be balanced with commercial (proprietary) considerations.
 

Morlock

Involved In Discussions
Thanks Ronen. The plan going forward is to hold the IFUs as a way to understand and document the "User Needs" (a recommendation from the auditor and a couple of colleagues). That way we can directly reference the IFU as well as the provided spec docs within our risk assessment. This should satisfy 4.2.3.a. The other sub-clauses will be addressed as they pertain to our internal processes.

Follow-up questions: How often should the IFU/MDF/risk assessment be reviewed, and who's responsibility is it to ensure the IFU we have on file is current? I would think that a significant change to any of OUR processes would trigger a review of any related risk management docs, obviously, but what about changes to the IFU from the customer's perspective? Should they send us a new doc every time their IFU is updated? Or would updating us only if their user needs change be sufficient?

Thanks all!
 

Ronen E

Problem Solver
Moderator
Your MDF should be kept up to date at all times (by way of having all contributing processes include instructions to update the MDF at the relevant spots), and I would recommend a proactive, comprehensive review at least once in every 12 months (maybe 6 months if you have a lot of changes).

Similarly, risk management files should be considered "live" and updated in real time wherever anything significant changes.

If you intend to rely on your customers' IFUs, you should definitely have the latest revisions on file at all times (within reason). If you can add a clause to the contract saying that they will share with you every new revision as it is released, that's recommended. Otherwise you'd have to proactively reach out once in a while to check whether the revision you have is still the latest. I would say at least twice in every 12 months, preferably once a quarter, unless these IFU's update quite seldom (then maybe check once a year).
 
Top Bottom