60601-1-8 Compliance

[AngelRose]

Good evening everyone,

I'm currently tackling a non-conformity raised by our Notified Body and it pertains IEC 60601-1-8 so I'd really appreciate any insight or shared experience from you...

Our medical device includes visual indicators (LED lights) that illuminates in the event of a fault. The device's design relies on a fail-safe architecture, so that whenever a hazardous or abnormal condition is detected, the system automatically shuts down and enters a safe state, independently of user intervention.
In our Technical Documentation, we initally proposed a rationale that these lights did not constitute an alarm system according to the standard since no user response is required to reset a condition as they were mere visual indicators that serve to inform rather than alert in a formalised sense.

Our NB disagreed and pushed it back, since according to our Risk Analysis, these luminous indicators (plus the error message pops up in user interface) were in fact risk controls.

My first instinct was eliminating any references to these indicators in my Risk Analysis thus confirming the IEC's non-applicability (though I doubt it will be acceptable).

The alternative is mapping all possible warnings and relative "alarm conditions, classifying them by alarm type and priority, and specify the required actions - treating them as formal alarms in line with the standard's definition. Will this be sufficient?

At this point, what I'm trying to comprehend is what specific evidence or structure does my NB expect when evaluating conformity to IEC 60601-1-8. Has anyone used a checklist or structured template for evaluating conformity?

I thank you in advance for any opinions, strategies or tools

 

[mr9000]

If you have any condition, where the essential performance of the device is no longer given, and you alert the user of that, that would be an alarm. More so, if you rely on that signal in your risk analysis as a protective measure.
See Note 1 of 4.3

NOTE 1 The performance of the RISK CONTROL measure might well become an aspect of the ESSENTIAL PERFORMANCE of the ME EQUIPMENT or ME SYSTEM. For example, the generation of the ALARM SIGNAL to indicate the interruption of the SUPPLY MAINS could be “essential” if an interruption of the SUPPLY MAINS could result in an unacceptable RISK if it went unattended.

There is a Test Report File for the 60601-1-8, but that is nothing more than all the requirements of the norm in a table. So with the norm, you could built your own file. Link the necessary requirements to your technical documentation and risk management file, and you show conformity with the norm.

 

[Peter Selvey]

Most cases of "failure to perform" indications should be INFORMATION SIGNALS.

A very common situation for modern medical devices is a low battery indication (battery too low to function) which is not normally treated as an alarm even though essential performance might not be possible. A specific example is a home use electronic thermometer which has well defined essential performance in the particular standard, and shows an indication when the battery is too low to function. Such an indication would not normally be considered an "ALARM SIGNAL" under IEC 60601-1-8, and would be treated as an INFORMATION SIGNAL if anything. Note that according to the standard for thermometers, if the battery is too low to function, they can choose either a TECHNICAL ALARM or to blank the display of temperature.

There are of course higher risk devices like an infusion pump, dialysis machine, infant incubators where failure to provide essential performance needs an real alarm. However as a point of reference even IEC 60601-2-16 for dialysis allows the use of an INFORMATION SIGNAL for technical faults as long as the blood system is running, suggesting that "failure to perform" only requires a real alarm condition if it is serious. And keep in mind, alarms are a pain to operators, so we need to act with some restraint when using alarms.

Some background here. It's important to note that the scope of IEC 60601-1-8 is unusual. Typically, a scope statement will say this standard applies to X and then X is a defined term. In this case, the scope appears to be written to apply to all ME equipment, which on one level kind of makes sense, since it includes requirements for INFORMATION SIGNALS which are not alarms. However, practically the standard is onerous to apply if there are just INFORMATION SIGNALS, so the most common interpretation is to skip it unless there is at least one ALARM SIGNAL.

What then is an ALARM SIGNAL? The original IEC 60601-1-8 was a bit of a mess as the definitions of ALARM SIGNAL, ALARM SYSTEM and ALARM CONDITION were simply a circular reference, with each definition simply referring to the others, in an apparent assumption that everyone magically knows what an "alarm" is. This was partially fixed in Amendment 1, with the addition that an alarm condition was where "an actual or potential HAZARDOUS SITUATION exists for which OPERATOR awareness or response is required". This also ties in with Clause 4, which provides the link that if raising the awareness (notification) of the operator is considered a risk control measure, then it is (in effect) an ALARM SYSTEM.

The residual problem here is the failure to distinguish between direct harm and indirect harm. In the original IEC 60601 series (which included IEC 60601-1-8), the standard only applied to direct harm (it was explicitly stated). In the "3rd edition", this was quietly expanded to include both direct and indirect harm. As examples, a thermometer that reads wrong value is indirect harm, whereas a thermometer tip with a pre-heat function that goes crazy and burns the patient would be direct harm.

While it is important to include both direct and indirect harm, the problem is they need different handling in risk management. Generally, indirect harm has several more "ifs" in the sequence, more people involved (patient, operator, healthcare professionals), tend to more difficult to eliminate, and overall more messy, as a result it's reasonable to have a more relaxed risk acceptability criteria (for example, 1 in 10,000 per treatment for serious harm). Direct harm though is usually more simple, easily preventable at low cost, so "1 in 1,000,000" per year is a reasonable threshold for serious harm, which despite appearing very low is reasonable and attainable in many cases.

Unfortunately, current risk management lumps both direct and indirect harm together in the main risk management table with the same criteria, leading to complications, both overkill and underkill.

Anyway, the point is that if the indication is associated with indirect harm it should not in most cases require a formal "alarm" according to IEC 60601-1-8, even if it is shown as a risk control measure in a risk management table. While this conflicts with the text of the standard, there are many many examples of indications that are useful information and a reasonably considered risk control measure, but would not be reasonable to be an ALARM SIGNAL according to IEC 60601-1-8.

 

[AngelRose]

Thank you all very much for the very very exhaustive feedback!
I'm currently drafting a rationale based on the points you've raised, using the terminology used in the collateral standard.
Understanding the nuances around alarm signals versus information signals is not very easy, so thank you for the reference points provided...

 

[Tidge]

The only nuance I'd add to @Peter Selvey analysis above is that I've had my risk management file distinguish between:

• Technical Alarm Conditions, and
• Physiological Alarm Conditions

The alternative is mapping all possible warnings and relative "alarm conditions, classifying them by alarm type and priority, and specify the required actions - treating them as formal alarms in line with the standard's definition. Will this be sufficient?

That is what I did, with a grid of "time before onset of potential harm" and "severity of harm". The ALARM CONDITIONS with low severity and (highly) delayed onsets are essentially indistinguishable from INFORMATION SIGNALS. IIRC 60601-1-8 allows for "no ALARM SIGNAL" in such cases anyway.

In common parlance, "alarm" can be used to mean things outside the scope of 60601-1-8. I've found that the vernacular can really get in the way of a meaningful risk analysis... and sometimes NRTL certification against 60601-1, because generally the NRTL doesn't want to grok the manufacturer's risk management file and/or usability analysis. If the manufacturer can avoid using the word "alarm" except in a (rather strict) 60601-1-8 sense (even in the IFU). This is clumsy, but it can avoid the sort of "gotcha games" that some NRTLs will play.

 

[Al_Z1]

Well. I took a different path in my risk analysis. While I had an visual and audio alarm as a risk control measure, i narrowed it to one audio alarm and one visual alarm, than classified these alarms via IEC 60601-1-8 as auditory signals (medium lvl), provided needed audio auditory signal (compliant sample is included into links inside IEC 60601-1-8) than we made tests within our internal test lab (we have ISO 17025 compliance in several fields including noise level measurement) and provided test reports (assessing the whole IEC 60601-1-8 applicability to our device and alarms) to our NB. It was Ok for NB.
But testing audio alarm against IEC 60601-1-8 requirements is not trivial. You need to provide measured signal form (i.e. pulses quantity, length etc. rise up and rise down periods), needed base and additional frequiencies noise level etc. It took quite an amount of time to solve all this.

 

[Tidge]

But testing audio alarm against IEC 60601-1-8 requirements is not trivial. You need to provide measured signal form (i.e. pulses quantity, length etc. rise up and rise down periods), needed base and additional frequiencies noise level etc. It took quite an amount of time to solve all this.

So very true. Keeping this analysis out of the hands of the NRTL is probably a good thing.