Risk Management for IEC 60601-1 and IEC 60601-1-2

[ga2qa23]

Hello All, I have a prototype medical device (Class 2 with software and PCBs inside and Bluetooth capability) that's also handheld by a surgeon. I hired a consultant to help our team establish a risk management procedure that is compliant for getting certification to IEC 60601-1 and IEC 60601-1-2. However, I think I got a bit swindled. The consultant literally gave me a gigantic checklist of every single clause from both standards, with a column that basically asks "does this clause have possible issues with your medical device?". The consultant expects my team to complete the entire checklist, and create unique "Hazard Identification Numbers" for every individual issue, and then funnel all the Hazards into a separate risk matrix where I assign probability, severity, RPN, controls/mitigations, etc. The consultant said I basically don't need to do an FMEA if I use this huge checklist.

This gigantic checklist seems ridiculous. Does anyone else actually do it this way? Whenever I speak with colleagues, they always tell me to just do the Design FMEA instead and make sure it covers the same things mentioned in the standards IEC 60601-1 and IEC 60601-1-2. This makes much more sense to me.

I read through the ISO TR 24971 (the guidance document that accompanies ISO 14971) and I think it means I can just do the approach where I perform Design FMEA and use the standards IEC 60601-1 and IEC 60601-1-2 as acceptance criteria for any applicable risk mitigations.

Do I sound crazy here? What am I missing? I'd be glad to read any online resources you know of. Thank you.

 

[Tidge]

Hello All, I have a prototype medical device (Class 2 with software and PCBs inside and Bluetooth capability) that's also handheld by a surgeon. I hired a consultant to help our team establish a risk management procedure that is compliant for getting certification to IEC 60601-1 and IEC 60601-1-2. However, I think I got a bit swindled.

It certainly doesn't sound like you got what you needed (he writes, based on numerous interfaces with a NRTL for 60601-1 testing), but I definitely see something like evidence that you may not know enough to get what you need.

The "clause-by-clause" breakdown of the standard is something the NRTL will almost certainly ask you to do... but it is NOT a risk management approach. I would also not try to skate by on only a DFMEA... minimally, you seem to have recognized that some of what the consultant suggested (the terms you list do strike me as correct ones for the conversation) wouldn't fit in a DFMEA. For much of 60601-1 a DFMEA could be used to establish hooks to hang design choices that will (eventually) help you pass certain tests... but without an actual risk management process you won't pass clauses related to RISK MANAGEMENT (4.2)

 

[ga2qa23]

The "clause-by-clause" breakdown of the standard is something the NRTL will almost certainly ask you to do... but it is NOT a risk management approach.

OK so does that mean the consultant definitely swindled me?

minimally, you seem to have recognized that some of what the consultant suggested (the terms you list do strike me as correct ones for the conversation) wouldn't fit in a DFMEA.

So how does one actually do risk management per IEC 60601-1 and IEC 60601-1-2. There are no clear expectations/examples. It's incredibly vague/nebulous for standards that every electrical medical device in the modern world needs to get certified to. I read/heard that you want both a bottom-up approach (FMEA) and a top-down approach (Hazard Identification) as part of a comprehensive risk management procedure. So should I use a top-down approach for IEC 60601-1 and IEC 60601-1-2? Is there a template I can buy online to help me get started?

 

[Tidge]

First, my perception of NRTLs and 60601-1 testing. This is just MY opinion from the USA, and should not be considered accurate or factual. I don't believe that NRTLs were "fully" on-board with the transition to 60601-1 3rd edition that explicitly made Risk Management (per 14971) the foundation of 60601-1. I completely believe that collectively the NRTLs recognized that 3rd edition would require more testing... which would lead to more $$$ and improved safety profiles... but my interaction with NRTLs has been such that to describe them as "rookies" in RM might be considered insulting to rookies in other areas.

Having written the above... it should be possible to survive contact with a NRTL with ONLY a DFMEA, especially if you are only in the prototype phase. They may give you some sort of limited 60601-1 "certification" but I don't precisely know what that would mean for you... without being ready to ramp up production (and get regulatory approval)... would you be insulted if I wrote that my guess is that you are hoping to get someone else to buy your design?

In any case, I would recommend that you bluntly recognize that you are (at this point) ONLY trying to do a preliminary risk analysis. I prefer a TOP-DOWN approach because it will be more evident what you are NOT doing. (I am making some hand-waving gestures to represent a few things you will need, that a decent consultant would have been able to hand you drafts/examples of)... take those things and generate a Preliminary Hazard Analysis. Plan to have almost everything in this PHA point to the DFMEA that you already think you would be comfortable generating. Some things in the PHA won't fit nicely with the DFMEA... but those are gaps that you can fill with a more mature Risk Management process... and the second round of consultants.

[one of the trickier elements of clause 4.2 is that you have to have an established process for RM, but I am willing to bet that you could have some skimpy documentation that a NRTL will accept as evidence of a process. It's not the approach I would take, but maybe you got a consultant that hasn't set up quality system elements for clients?]

BTW, I believe that if you ARE trying to sell the prototype design to a 3rd party... this sort of RM information will increase the value of the design, at least as much as whatever 60601-1 testing will provide (for a prototype).

 

[ga2qa23]

We're not trying to sell-off our prototype design, we're trying to get to market and sell it ourselves. We also have a risk management process that we already got from a consultant and it's fully developed aside from that last annoying piece for IEC 60601-1 and IEC 60601-1-2. We already have DFMEAs, a Hazard ID checklist for ISO 14971:2007 Annex C, and a Hazard ID checklist for Usability from IEC 62366.

You just keep saying to hire rounds and rounds of consultants but the latest one I hired apparently failed me pretty hard. So I wanted to please ask for some guidance as to what a "mature" risk management process actually looks like. What does this "top-down" even mean for IEC 60601-1 and IEC 60601-1-2? Everything is a document at the end of the day. How can we get started when the consultant we hired couldn't give us the right document template to start with?

 

[Peter Selvey]

Few things here. First is that it's widely recognised that while an FMEA can be useful isn't the end of the story. Generally, it's impossible to cover all the failure modes, but an FMEA can still give pointers to the things that need to be covered in risk management. In the end a good risk management should be based around robust protection features; robust to mean kind of broad spectrum, covers lots of potential causes.

For example, if Bluetooth coms is critical for the procedure, rather than focusing on all the things that could go wrong with the communication (FMEA), it's better to focus on establishing broadly effective risk control measures (backup communication channels, data checking, perhaps having a back-up device available during the procedure, excellent battery management, ensuring a good signal strength, controlled separation distance to the base station etc).

Next is that risk management can never cover everything. Your team will have to decide it's own "filtering" method to decide what goes in or out of the written file. Some of the stuff e.g. signal strength I mentioned above might be so obvious to an experienced Bluetooth engineer and this is the nth iteration of a well established system that it's pointless to list it out as a line item in a risk management table. On the other hand, your software engineer might be moonlighting as Bluetooth guy and really has no idea what they are doing, then perhaps a risk management line item on signal strength could be good value. It's really case by case, depends on the technology used, experience and so on. But the key point is, don't worry about trying to cover everything in a risk management file, it's OK to rely on common sense, qualified engineers using well established methods without writing them all up as a line item in a table. Focus on the unusual stuff, not obvious or areas where your team might be out of their depth.

Finally ... IEC 60601-1 is a pain because it embeds risk management in the standard and the test lab needs to write these up irrespective of how bureaucratic this may seem. However (big point for your post), there are only a limited number of clauses that do this. There are roughly 1500 items in an IEC 60601-1 checklist, I think less than 50 actually involve risk management, and around 10 or 20 might be applicable to your particular device. So your consultant should be providing you with a list of these 50 items, check which ones are applicable, and for the applicable ones, make sure they can find the particular line item in your risk management file.

So, yes it sounds like your consultant is being lazy.

 

[Tidge]

So I wanted to please ask for some guidance as to what a "mature" risk management process actually looks like. What does this "top-down" even mean for IEC 60601-1 and IEC 60601-1-2? Everything is a document at the end of the day. How can we get started when the consultant we hired couldn't give us the right document template to start with?

Here is what I would consider as evidence of a 'mature' RM process:

A RM Plan and RM Report. The Plan should minimally include plans for periodic risk reviews, and links to other feedback systems (required by 13485 and 21 CFR 820, anyway) The RM Plan could be the sort of document that gets accepted as proof of compliance with 60601-1 clause 4.2.

A Hazard Analysis that derives from things like a Hazards Checklist, a List of Harms, and the Use Scenarios. This is all you need to do a coherent job rating things like "S", "P1", "P2" for risk acceptability.

Upon completion, the HA should be supported by a Risk Controls Option Analysis and a Benefit/Risk Analysis.

The HA can be supported by subordinate documents like a DFMEA. Most manufacturers also incorporate PFMEA, and most usability experts will consider a UFMEA essential. If there is software, you will have some sort of RM document for software as well.

I could go into MUCH more detail, but this is what I would expect to see.

 

[Developer_Germany]

Please keep in mind that compliance to ISO 14971 is one thing. The other one is compliance to IEC 60601. For the latter one you might go to a testing laboratory to receive a CB Test Report. And therefore they will ask for a comprehensive link between the 60601 requirements and the risk table according to 14971.
See also
"Guideline Document on Medical Electrical Equipment in the CB Scheme according to the IEC 60601 and IEC/ISO 80601 Series of Standards"
IECEE OD-2055
iecee od-2055

 

[Tidge]

We're not trying to sell-off our prototype design, we're trying to get to market and sell it ourselves. We also have a risk management process that we already got from a consultant and it's fully developed aside from that last annoying piece for IEC 60601-1 and IEC 60601-1-2. We already have DFMEAs, a Hazard ID checklist for ISO 14971:2007 Annex C, and a Hazard ID checklist for Usability from IEC 62366.
[...snip...]
How can we get started when the consultant we hired couldn't give us the right document template to start with?

Are you sure you didn't get what you need? Obviously there is some sort of communication breakdown, some of which belongs to the other party. After letting this part of the post sit with me for a while I'm thinking I see evidence of communication breakdown on both sides.

Normally, when I am working with a team that will be submitting an ME device to a NRTL for 60601-1 certification, we start with a checklist derived from applicable standards (60601-1, collaterals, and if applicable a particular) plus any national variants for target markets. Think of this as a "Design for Compliance" exercise. This has the look of a "gigantic checklist".

Once we have this completed, the necessary work gets doled out. Specifically for ME safety elements derived from the standard, there will be specific requirements that will find their way into the Risk Management documents (as risk controls). A general example: In the electrical hazards section of the Hazard Analysis, for a give use scenario, there could be a risk of "shocking" a patient (or user) (derived from 60601-1 section 8). In such a case, a simple risk control could call out something like "compliance with clause xxx" with the VoI being something like an insulation diagram and the VoE being the report of compliance from the NRTL. (this is just a simple story).

 

[ThatSinc]

So I wanted to please ask for some guidance as to what a "mature" risk management process actually looks like

For me, a mature risk management process looks fully integrated.
The requirements of 60601-1 would be assessed within the standard process and not look like it's bolted onto the side as an additional piece of work to satisfy the standard. The same goes for integrating 62366, 62304, 60601-1-8 and any other standard that requires you to have a risk management process.

That's not to say that you shouldn't use the standard as the basis for a lot of the content in the "Design for Compliance" exercise that @Tidge mentions, definitely take credit for the risk management activities that standards have already done for you.
e.g. 60601-1 requires you to identify essential performance. Various particular standards will define essential performance for you, and as such you can use this to your advantage - but it should fit into your existing risk process documentation.

The HA can be supported by subordinate documents

Do you think it's possible to document the relevant requirements of 60601-1 related to risk without any of the subordinate documents mentioned?

Particularly clause 4.8 on failure of components that could result in a hazardous situation and 4.9 regarding components with high integrity characteristics.
Is there a logical way of assessing and documenting, without the use of a component level dFMEA, whether component failure would lead to a HS, or whether it would result in unacceptable risk?

Where a Hazard Analysis is structured to include the Hazard, Hazardous Situation, and Harm - there doesn't seem to be an ideal way to do this.