But Why Don’t Medical Devices Need IEC 61508? A Look at the Latest Developments in IEC 60601-1 Edition 4

As the 4th edition of IEC 60601 heads to the committee draft version (CDV) 2nd stage in 2026, the question of functional safety or rather embedded system safety crops again. In late 2024 and 2025, a number of posts on social media discussed why the medical device sector does not need IEC 61508 – the standard for functional safety of electrical, electronic, and programmable electronic safety-related systems. With that, the inclusion of medical devices within the scope of IEC 61508 has been officially rejected at the end of 2024. And yes, while IEC 61508 may be excessive for the vast majority of medical devices, we do need a solution for the lack of embedded safety coverage in IEC 60601. In this blog we look at some of the challenges of developing safe embedded systems and how the medical device sector could improve its strategy.

Are we afraid of functional safety?

Within the IEC 60601 community, there appears to be a reluctance to acknowledge the term functional safety. There is no doubt that the subject is complex and brings many challenges which, for the vast majority of medical device manufacturers, would be over the top. However, there are medical devices where functionality has safety-related implications, some of them critical. How does the industry support such customers?

The programmable medical electrical systems (PEMS) architecture section of the CDV 60601 edition 4 has not changed from edition 3 – the current version. A technical report, IEC 60601-4-9, has just completed its review phase (19 December 2025). Ultimately, however, IEC 60601-1 itself should support customers facing these challenges, rather than relying on a technical report. Section 14.8 of IEC 60601-1 edition 3 introduces a number of key terms, which we will look at in a bit more detail.

Common-Cause Failures in Medical Device Architectures

A common-cause failure occurs when two or more blocks in an architecture fail due to a single specific event or root cause.

In the example below, two redundant sensors are introduced to mitigate the risk of a single sensor failure. However, this raises further questions:

• What about common hardware, i.e. the same sensor type?
• Or the common software and hardware within the microcontroller that reads the sensor data?

There are ways to improve the architecture, such as using diverse sensor types or implementing diverse software, partitioned inside the microcontroller.

Figure 1. Common-cause failure example

Cascading failures

Cascading failures are not explicitly listed in section 14.8, but are indirectly referenced in section 4.7! A cascading failure occurs when a failure in one functional block results in failures in one or more subsequent blocks. This is of particular concern when the failing blocks are risk control mechanisms, as the benefit of having two risk control mechanisms is then lost. This phenomenon is often defined as the domino effect.

Diagnostic Coverage (DC): Detecting Dangerous Failures

Diagnostic coverage (DC) is a widely used term across numerous safety standards and guidance documents, with slight variations in definition. Using the more generic definition from ISO 13849, diagnostic coverage is a measure of the effectiveness of diagnostics and may be determined as the ratio between the failure rate of detected dangerous failures and the failure rate of total dangerous failures.

Diagnostic coverage is very much a system-level attribute, as both hardware and software can contribute to the level achieved. Diagnostic coverage can be estimated in three different levels: low (60% ≤ DC < 90%), medium (90% ≤ DC < 99%), or high (99% ≤ DC). Alternatively, diagnostic coverage may be determined through calculation or by applying fault-injection tests, with the activity then becoming more scientific and evidence-based.

A typical example of diagnostic coverage levels within a system can be explained by considering the detection of failures in a power supply output.

Element	Low DC (60%)	Medium DC (90%)	High DC (99%)
Power supply	Under and overvoltage	Under and overvoltage Drift	Under and overvoltage Drift & oscillation Power spikes

Table 1. DC examples for a power supply output

There are many system-level considerations when assessing diagnostic coverage. Sources such as IEC 61508 and ISO 13849 are helpful in defining DC for microcontrollers, bus systems, and analogue or digital I/O, to name but a few.

The main challenge associated with diagnostic coverage is relating it to a failure rate for the hardware components being analysed. This is where failure-in-time (FIT) rates from reliability sources come into play. The FIT rate of the hardware block or component is multiplied by the diagnostic coverage value, yielding a figure for the probability of detecting that given fault.

This approach takes failure modes and effects analysis (FMEA) to the next level, where both the occurrence probability and detectability columns become quantitative through the use of FIT and DC values.