Does 4.5 - Alternative RISK CONTROL apply to the Particular Standards?

[mwaller]

Section 4.5 in the General Standard 60601-1 says: "Where this standard specifies a particular RISK CONTROL measure or test method, an alternative RISK CONTROL measure or method is acceptable, provided ...."

Does this also apply to the Particular Standards? If so, where is this stated?

Thanks!

 

[Peter Selvey]

Yes, it applies to particular standards.

The structure of particular standards is that they modify the general standard. It is not actually correct to read the standards separately or to consider them as two standards, rather it is the single merged version which is "legally" correct.

When I first started working in this field (35 years ago!) the test lab would prepare reports this way, using a merged version. However, the CB scheme got lazy and started publishing separate protocols. Admittedly it's a lot of work, standards have got a lot bigger, more particulars, amendments etc. Nevertheless, it can lead to errors if the standards are read and evaluated separately.

 

[Tidge]

I worked on an ME device with a particular standard that (successfully) leveraged clause 4.5; although in our case the clause was specifically invoked for one small part of a collateral standard. Without going into detail: for the type of device in question there is a clause in a collateral standard (not addressed in the particular) that appears to exist because of some underlying assumption about the way all medical devices are used, but in practice does not apply to a majority of devices in a surgical theater. There is a lot of literature on the subject, our own formative testing revealed that complying with the clause was not only against established clinical practice but was interfering with task performance and generally making performing critical tasks very difficult. In other words: there was a requirement of the standard that was not really reducing any risks but was introducing (and increasing) risks.

It wasn't easy to get the NRTL to accept the alternate risk control method. An ironic element of this story is that despite us calling out that we were invoking clause 4.5, the NRTL missed it. We had to circle back to them to get them to recognize it because (a) it was the right thing to do and (b) we didn't want to risk a "last minute" test failure showing up... but it then became a nightmare to get them to accept the volumes of data (including a significant amount of user validation and published literature that defended the alternate risk control as more effective than the one in the collateral. We already had all of this in the DHF and it was all referenced within our risk files, but they all but made us repeat validation.

I was left with the impression that the NRTL took this approach with us for a mix of reasons:

• Human factors: They were embarrassed at having missed something we called out for them on the checklist.
• Work Experience: Despite the (now) long history of requiring risk management as the basis of 3rd edition, NRTLs have no practical experience with actually working through Risk Management. I literally had to explain what "verification of implementation" and "verification of effectiveness" meant.
• An inherent suspicion of any ME manufacturer who can't/won't follow a standard (for any reason, or no reason)

This interaction really soured me on the NRTL, because the long-standing test lead (who used to instruct the class on 3rd edition compliance) explained in the week-long class what was necessary to support invocation of clause 4.5... and as part of the class would point to certain 'basic safety' elements of the standard as being areas where the standard didn't quite make sense and so strict compliance wasn't necessary (with explanation). I found it extremely frustrating that he'd casually accept alternate risk controls when energy was involved but in terms of usability he was worse than a novice.

 

[yodon]

NRTLs have no practical experience with actually working through Risk Management.

Boy, does that really hit the nail on the head! And don't even get me started about NRTL's "understanding" of software under 62304!