Are risks in supply chain and development activities within scope of MDD?

[silentmonkey]

We are aiming for CE mark through compliance with MDD and the assessor has provided some feedback pertaining to our risk management activities. The verbatim we've been given is:

The assessor determines that the provided documentation does not provide evidence on conformity to essential requirements of Annex I of 93/42/EEC in respect to:
- Missing Identification of risks in supply chain and during development activities (e.g. HW, SW development)

I am debating internally whether or not this is a real finding as I do not see how risks in supply chain and during development activities has an impact on product safety. We have started developing a SupplyChainFMEA to address this finding and the risks identified thus far relate to operational and economic risks such as the severity and likelihood of supplier shortages. I do not think this is the correct solution as Annex I of MDD talks mainly about the safe design and construction... no where does it talk about risks in supply chain.

The only way I can make sense of this is if the assessor has just worded the finding poorly and is actually referring to downstream supply chain risks such as product reliability during transport/storage.

Is the assessor's finding legitimate?
If so, what clause or section in the MDD is it referring to?
Do you have any suggestions as to how we can address this finding?

 

[yodon]

Just speculating here but, for software, there is a certain level of expectation. 62304 (software) is a harmonized standard and so if it was followed, you have a presumption of conformity. It's been my experience that just asserting compliance is insufficient; they expect an assessment from an independent test lab. So if you outsourced software development to Joe's Waffle House and Software Development, they may push back. 62304 *does* drive a software-centric risk management process.

If you identified critical components then proper purchasing (incoming) procedures would drive an elevated level of receiving requirements (eliminate the possibility of counterfeit components). That's about all I can come up with for supply chain risks. One could argue that a shortage of parts would lead to the inability to produce product and thus delay therapy. A bit of a stretch but with the COVID / ventilator story, I can see that idea being pressed.

I presume you did follow ISO 14971 for product risk management?

 

[silentmonkey]

Just speculating here but, for software, there is a certain level of expectation. 62304 (software) is a harmonized standard and so if it was followed, you have a presumption of conformity. It's been my experience that just asserting compliance is insufficient; they expect an assessment from an independent test lab. So if you outsourced software development to Joe's Waffle House and Software Development, they may push back. 62304 *does* drive a software-centric risk management process.

If you identified critical components then proper purchasing (incoming) procedures would drive an elevated level of receiving requirements (eliminate the possibility of counterfeit components). That's about all I can come up with for supply chain risks. One could argue that a shortage of parts would lead to the inability to produce product and thus delay therapy. A bit of a stretch but with the COVID / ventilator story, I can see that idea being pressed.

I presume you did follow ISO 14971 for product risk management?

Thanks for the input Yodon! I think we are OK on the software development side of things.

Yes we will be classifying certain suppliers as critical if their components are critical to the safe and effective function of the product and there aren't sufficient controls in place to detect a loss of quality in the critical component, so this is driven by our risk management activities.

Indeed we have been following ISO 14971 for product risk management and this is where things get even more sticky. ISO 14971 defines safety as freedom from unacceptable risk; risk is defined as a combination of likelihood of harm and severity of that harm; harm is defined as injury or damage to the health of people, or damage to property or environment. In this context, supply chain risks are not within scope except for the point you raised about inability to produce product and delayed therapy which I agree is a bit of a stretch...

I am keen to engage with the assessor to clarify the finding and request that the assessor identifies the specific clause which he claims we are not fulfilling but there's some push back on this.

 

[levatorsuperioris]

Before you go guns ablazing against the NB, alot of assessors are looking down a shopping list of things they are looking for.
Notified Bodies and MDSAP AOs are required to audit critical suppliers unless they can duly justify not doing it through controls and in place with the manufacturer...

Worst case here is if you don't meet the standard the NB will have to audit the critical supplier before certification, given COVID, this basically may kill your chances before the MDD leaves effect. I suspect that I am reading between the lines in what you describing not only are you in territory of a real finding but also on precarious ground where things could get really ugly.

 

[CThom2409]

Hi OP - only just stumbled across this now so I'm sure you have this sorted, but thought I'd offer my view with experience in the impact of SC on device quality.

Supply chains impact business decisions, which can impact the thoroughness of supplier assessments, which impact specs and requirements; therefore it has quite a bit to do with the quality of the product.

It sounds like you're assessing based on criticality, which is great, but it's interesting that you're not seeing the inherent connection with product safety. Consider a situation where you are using a material with very particular properties with limited suppliers who can produce it to your requirements. Say that you went ahead with said supplier and down the line had a huge lead time impacting market entry and you're tasked with finding an alternative. Available alternatives may not be to the same spec you initially required, or could be of inferior quality and impact the performance of the device. All of that would have serious implications on your design + testing + risk and therefore can impact product safety. Tight deadlines and business pressure can also have a very real impact on how thorough an assessment is or allow concessions where normal situations won't. I'd say that's more what it's getting at.

Hope everything went smoothly![/QUOTE]