The face of compliance to requirements, compliance to requirements and intent behind requirements are three different things. While we want the last of the three, due to ambiguity and complexity we often end up spending far more time on the first two which in turn affects what is perceived as the things you must do to pass (the combination of requirements and faux-requirements).
True experts are a minority on both the auditing and auditee side, and standards (even when written by those experts) drift over time to the common consensus of them. In a world where time is seen as of the essence, sometimes yielding quickly (yet still unjustly) is a path chosen by (top) management. This also counts for the testhouses who use the standard test report as the base for testing (perhaps again a management decision, as I've experienced the tester group to consist of a larger proportion of well-versed people), introducing technically non-required expectations as hard hurdles (faux-requirements) to get into the market.
Technically faux-requirements are not enforcable, but you can choose between simply doing them or expending (a often disproportionate amount) of resources (time, money, personnel) to get what you want without doing them. As long as intent is met at a minimal cost way (both from the regulator side for (face of) compliance and the manufacturer side for getting past the compliance check), whether with or without faux-requirements, this is unlikely to change. The current dynamic between the manufacturers that need the certificates and the organizations that can issue them plays into this.
So while I could go the path of only describing the factually correct path, I also included the context of what usually happens in practice (whether just or unjust, right or wrong).
If a company has 13485 (a starting assumption of MDSAP) and MDSAP requires companies to treat certain parties as (if) suppliers, then those parties are likely to be streamlined into the existing 13485 process for that aspect. Having multiple processes specific to each regional requirement is less the norm than having a process that (tries to) handle a generic intent with the regional nuances integrated.
As for how many companies already made the jump to MDSAP versus doing it separately (and currently leaving Canada)? I'll grant you that number is still relatively low it should increase as consultants and the sector gain experience and increase the cultural mindset that MDSAP isn't all that much more than 13485 with regulatory requirements combined in a neat(-ish) package.
Despite that I look at it from the viewpoint of intent. While the idiosyncracies of the minutae of each regional regulation are enough to drive people mad, the intent behind those regulations is the same. Aiming a system at the intent instead of the letter of the law/regulation/standard will often give you better results, and in this case put you ahead of the game. MDSAP does/tried to do that. Make use of its useful bits, tolerate the less costly useless stuff and only fight the really stupid stuff.
As for critical component identification (to get back off-topic on that), the linked document in that thread states in 4.7:
"
4.7.1 The fourth section contains a table describing critical components and/or materials.
4.7.2 The information to be included in the critical components and materials table shall be based on the following:
a) The CTL clarification: "A safety critical component can only be determined upon a preliminary examination/evaluation of the electrical diagram/design/construction. When the design of the product is such that a determined component, in case of failure, can compromise the safety aspect, this component is defined as "safety critical".
b) Components, which have specific requirements in the end product standards.
c) Components, which have requirements in the National Standards included in the evaluation
d) Materials, which are critical to maintain compliance with the standard (such as corrosion requirements, flammability)
e) Professional judgment of the CBTL/NCB.
The evidence used to verify component compliance may be included as an attachment in the CB Test Report or available in the project folder. See also OD 2039 for further instructions.
NOTE: Additional information can be provided in the free text field of a Description row. For an example see Annex E.
"
b and c should be linked. a, d and e are relatively subjective, or at least subject to progressive insight as feedback is gathered and assessed through risk management. Can and does this go wrong a lot of the time? Yes. Our imperfect world with imperfect people. But even the trying makes us safer.
Back on-topic in an auditor-keeps-to-scope kind of way: whether they are justly or unjustly critical components doesn't matter as much for this thread topic: if listed as such they are especially prone to being checked for adequate and suitable supplier control. Thus the practical advice to not forget qualifying such suppliers.
Sorry about the verbose nature of it (and usually I like such nice discussions with a bit more
beer, which sadly won't work as you're on the other side of the world).