Choose another country to see content specific to your location

//Select Country

FAQs: Functional safety in medical devices

Undergoing tests is a critical step in the process of transforming an innovative design into a reliable and marketable product

FAQs: Functional safety in medical devices

  1. What is functional safety?
    Generally, functional safety deals with hazards, which arise from the function of a device. According to IEC 61508 it is the ability of a safety-related system to carry out the actions necessary to achieve a safe state for the EUC (equipment under control) or to maintain a safe state for the EUC.
  2. When do we have to apply functional safety? 
    We should apply functional safety in the following situations:

    a. significant risk is related to a function of a medical device, or

    b. product specific standard contains explicit requirements related to functional safety.

    Significant risk means that there is an unacceptable risk related to a function before risk mitigation measures have been applied or that there is a high severity (e.g. death or serious injury) behind a functional risk regardless of the probability.

    The second option is necessary because when a very low probability is assumed behind risks of a high severity, might result in an acceptable risk even before risk mitigation measures have been applied. Additionally, we need to challenge the evidence regarding this low probability and look into those functions as well.

    A typical example would be that the probability of a micro-controller failure is rated so low that the risk is acceptable without mitigation measures.
  3. Why is functional safety important?
    By undertaking risk analysis and manufacturing medical devices that are functionally safe, your company benefits from increased market acceptance and positive brand associations. Failure to ensure functional safety can have dire consequences.
  4. The functional safety philosophy
    The following six items build the basis of a functional safety evaluation:
    1. A first random hardware failure can occur at any time at any place.
    2. The first failure shall not cause an unacceptable risk.
    3. If the first failure is obvious to the operator, the device will no longer be used and it will be fixed (operators manual!). End of procedure.
    4. If the first failure cannot be detected, then after some time (MFOT*) a second failure has to be assumed.
    5. Also, the combination of first and second failure shall not cause a hazard.
    6. End of procedure. Note: The occurrence of three independent random hardware failures is usually not assumed within the typical lifetime of an electrical medical device (valid only for functional safety.
  5. What is the Multiple Fault Occurrence Time (MFOT)?
    The MFOT is the time in which two independent failures can be neglected.

    For some products the MFOT is defined in the respective standards. For instance, the MFOT for infusion pumps is defined as the replacement time of the disposable. It is worth noting that there are some other standards which are lacking a definition. However, it is common that the MFOT is assumed to be in the range of one treatment (in case the treatment is not too long), once a day etc.

    For simple components where a high reliability can be shown by objective evidence the MFOT can be extended (e.g. a high reliable emergency stop button might be tested once a year during the regular safety inspection).
  6. What is the Mean Time Between Failure (MTBF) or the Mean Time To Failure (MTTF)?
    The mean time between two failures is the average time between two failures. The mean time to failure is the average time till a (first) failure. The probability of those event is ~50% at those points in time. Those times are significantly higher than the MFOT (e.g. a factor of 100).
  7. What is the fault tolerance time (FTT)?
    The fault tolerance time describes the time an error can persist before it gets dangerous. In contrast to the MFOT, the fault tolerance time depends on the hazard.
  8. Why are self-tests required?
    Self-tests of the device help to make a sleeping first failure detectable/visible to user. In case they are visible, point #3 of the philosophy applies.
  9. How often should the device execute a self-test?
    Self-tests have to be executed at intervals smaller than the multiple fault occurrence time (MFOT).
  10. Which architectures are suitable to fulfil functional safety?
    The most common system architectures, along with their suitability and requirements regarding functional safety are described in the table below. The control system controlling the function (relevant to functional safety) is marked as C and the protective system is marked as P.

    The example shows a simplified part of a baby incubator. The hazard used as example is over-temperature (temperature above 41 °C). The control system is responsible for controlling the temperature e.g. with a closed loop controller. In the event when the temperature reaches 41 °C, a protective system has to turn off the heater. *Remark: other parts of the system, like sensors are not shown.
Simplified architecture
Suitability and requirements
Functional safety - Pure control system (C)
Pure control system (C)

"Not suitable"

A pure control system (C) is not acceptable for functional safety as it violates item 2) of the philosophy.

Functional safety - Control system + independent shutdown path (C + WD)

Control system + independent shutdown path (C + WD)

"Could be acceptable"

Requirements for self-tests:

- self-tests of C in times ≤ FTT and the category "medium" according to IEC 61508
- self-test of the watchdog + shutdown-path in times≤MFOT and the category "simple" according to IEC 61508 or functionality as black-box

A control system which has an additional watchdog might be acceptable. However, this is complicated to achieve because the entire functionality of the control system must be tested in the fault tolerance time. In addition to that, with increased deepness of the self-test (category medium according to IEC 61508). The watchdog including its shutdown path has to be tested in the MFOT.

It might be possible to reduce the self-tests by implementing a diverse (not redundant) control and protective system within the only physical channel. The diversity will be such that no single hardware failure affects both channels in the same way. Potential common-mode-failures still needs be covered by the intense self-tests mentioned before.


Control system + protective system (CP)

"The standard case"

Requirements for self-tests:

- self-test of P in times≤MFOT and the category "simple" according to IEC 61508. The self-test can be done piece by piece or as black-box for the functionality.

A control system with and independent protective system is widely used in functional safety. The protective system has to be tested in the MFOT (category simple according to IEC 61508 or as black-box).

Functional safety - Control system + protective system (CPP)

Control system + protective system (CPP)

"This case used when self-tests are not possible"

Requirements for self-tests:

- none

A control system with two independent protective systems does not require any self-tests. This kind of architecture is typically used when self-tests are not possible - e.g. for over-voltage protection.  

Functional safety - Control system + protective system in one piece of hardware (CP in one hardware)

Control system + protective system in one piece of hardware (CP in one hardware)

"The complex case"

Requirements for self-tests:

- the level of self-tests needed for the controller (C and P) depends on the diversity of C and P
-self-test of the watchdog + shutdown-path in times≤MFOT and the category "simple" according to IEC 61508 or functionality as black-box

If you have any questions relating the functional safety of medical devices, please contact us at [email protected].

EXPLORE

Smart healthcare
Stories

Smart Healthcare

New technology for successful ageing

Learn more

The Future of Healthcare
Stories

The Future of Healthcare

Overcoming hazards in connected healthcare

Learn more

Wearable Doctors
Stories

Wearable Doctors

Transforming the way we track, manage and improve our health

Learn more

VIEW ALL RESOURCES

Next Steps

Select Your Location

Global

Americas

Asia

Europe

Middle East and Africa