IEC 60601-1-8:2020 Is it necessary to change the alarm melody?

[TKroenert]

The IEC 60601-1-8:2006 AMD2:2020 changed the requirements regarding the (musical) sound of an alarm by replacing Annex F (Alarm Melodies) by Annex G (Alarm Sounds, .wav files in questionable quality provided online). It is further noted that the adoption of Annex G is expected in 60601-1-8:2024.

Does this change necessitate an update of our product already used in the field?

My concerns are about the users receiving different alarm sounds from identical devices during the transition phase.

 

[Peter Selvey]

I haven't got a copy but this kind of change can trigger a backlash and delays in adoption, especially if there are as mentions wav files of questionable quality, and poorly considered transitional aspects. Might be good to watch closely to see if Europe adopts it as an EN standard - or was it a joint publication (fast track)?

 

[Judy Edworthy]

I'm interested as to why you consider the .wav files to be of questionable quality. What is it specifically you are questioning the quality of? I can assure you that great effort and care was put into the preparation of the files before they were posted. I'm interested to hear more

 

[Tidge]

It is unlikely that you would have to change product in the field simply because an element of the standard changed. You can of course consider it yourself (via periodic risk review) even without be forced into it... from internal or external pressure.

I haven't reviewed the specifics of 60601-1-8 (2020 amendment, or proposed). I have a LOT of respect for 60601-1-8, especially in the way it links to the risk management process for the categorization of ALARM CONDITIONS, and the clear difference between TECHNICAL and PHYSIOLOGICAL alarms. I have the (older, likely outdated) sense that the collateral has a peculiar assumption that (my words) "any user should be able to tell the PRIORTY of every alarm by adopting a common set of audible ALARM SIGNALS". This irritates me for two reasons:

1. Generally, the consensus standards for medical (electrical) devices are design agnostic, as long as they satisfy basic safety and essential performance. I can certainly accept the basics for VISUAL and AUDIBLE alarm signals just as I accept certain basics of electrical safety... but I often had the feeling that the (collateral) standard was heading into specifics for poorly motivated reasons.
2. Usability. ALARM SIGNALS (and to some extent, the PRIORITY of ALARM CONDITIONS) do not exist independent of the use cases. As dedicated professionals well-versed in Risk Management, Product Design, and User Validation... we can make a sincere effort to establish (and disclose in accompanying documents) the alarm scheme for our devices... however... I can testify without hesitation that if every device in a surgical theater made the exact same audible alarm (for some set of alarm conditions derived independent of consideration of all the other devices in the room) that surgical teams would experience enough confusion that patients would be at risk.

My text around (2) is independent of the (also serious) concerns that users will likely have if existing, familiar devices have UI modified. I think this may have been what @Peter Selvey was referring to? We (designers) do have to occasionally pull our customers into the "now", but specific to the case of ALARM SIGNALS for existing, familiar designs there are some design choices that could introduce more risk to patients than is tolerable.

 

[mr9000]

I refer to 6.3.3.1, where it states in d) that you can use the melodies from the .wav-files from Annex G (1.) but still allows in 3. to meet the requirements in Table 3 and 4, which can refer to the melodies specified in Annex F.

 

[TKroenert]

I'm interested as to why you consider the .wav files to be of questionable quality. What is it specifically you are questioning the quality of? I can assure you that great effort and care was put into the preparation of the files before they were posted. I'm interested to hear more

I was confused by the audio quality, which sounds minimalistic and intentionally distorted by reduction, as if it's meant to be produced by a small piece of hardware.
But from a designer's perspective, the sound is still complex and needs to be stored as a waveform with over 240,000 samples. However, if the sound is stored as a waveform, there is no need for the minimalistic sound and reductions. Even a voice output would then be possible.
This applies to the icon sounds.
The pointer sounds run in a loop with the same 100 samples (at 44.1 kHz). This is pretty much the same as the old sounds.and fits into even the smallest microcontroller.

Maybe I missed some tricks, and I'm glad to hear here how others solved this.

@Tidge: thank you for the comment. Fully agree with the context to the risk analysis and I really appreciate your term of <<occasionally pulling our customers into the "now">>.