Have you considered functional safety for your medical device? And if not, do you have an overview of what functional safety actually is? If not, I would like to give you an introduction to the topic in this article. Functional safety is no longer just a must in the automotive sector; it is gradually making its way into medical technology as well.
What does functional safety actually mean?
The term “security” is defined in ISO 14971 as the Freedom from unreasonable risksFunctional safety refers to that part of a system's safety that depends on the correct functioning of the safety-related system and other risk-mitigating measures. Functional safety does not include, for example, electrical safety, fire protection, or radiation protection.
When do we need functional safety and which standards apply?
Functional safety should be applied when the system, without considering risk control measures, poses unacceptable risks related to its function. This applies, for example, when the medical device could cause death or serious injury to the patient. The assessment should be independent of the probability, but should only refer to the severity of the harm. The standards applicable to functional safety are:
| standard | title |
|---|---|
| IEC 61508 | Functional safety of safety-related electrical/electronic/programmable electronic systems |
| IEC 60601-1 | Medical electrical equipment – General requirements for basic safety and essential performance |
| IEC 62304 | Medical device software – software lifecycle processes |
The philosophy behind it
A first error can occur at any time and at any point in a medical device. The first error must not result in an unacceptable risk. If the first error is detected and becomes apparent to the operator, further errors need not be considered, as it is assumed that the product will not be used any further. This should also be documented in the instructions for use!
If the first error cannot be detected, it must be assumed that a second error will occur after a certain period of time. In this case, the combination of the first and second errors must not result in an unacceptable risk. The consideration of further errors is not usually carried out within the scope of functional safety.
Definition of terms
| abbreviation | English | German |
|---|---|---|
| MFOT | Multi-fault Occurrence Time | Time for multiple errors to occur |
| FTT | Fault Tolerance Time | Fault tolerance time |
| MTTF | Mean Time To Failure | Mean time to failure |
| MTBF | Mean Time Between Failure | Mean time between failures |
MFOT indicates the time during which two independent failures can be ignored. You should specify this time for your product. For infusion pumps, this time is defined in the relevant product standard. Typically, the MFOT can be assumed to be the time for a single treatment, provided the treatment duration is not too long (e.g., more than one day). This means that a self-test at device startup, which detects a possible initial failure, does not need to be repeated during treatment, provided the treatment duration is short enough.
The FTT describes the time a fault exists before it becomes a hazard. This time is often relatively short. You must consider this time when designing protective measures. The protective measures should take effect faster than the FTT so that the protection is effective in a timely manner.
The MTTF indicates the average time until the first failure occurs. The MTBF indicates the average time between two failures. These times are significantly longer than the MFOT (a factor of >100).
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
Interpretation of self-tests
A self-test can help identify an initial error and make it visible to the user. Then, further error analysis is no longer necessary. To ensure an effective self-test, the self-test must be performed at intervals shorter than the MFOT.
Architectures in functional safety
In the following, a few simplified architectures are shown to highlight the aspects of functional safety.
1) System without functional safety
The first diagram shows a control system that controls an actuator and reads a sensor. This allows for closed-loop control. There are no protective measures, and the first error in the control system leads directly to patient harm. This is unacceptable from a functional safety perspective.
2) System with protection system
The second diagram has only one protection system, such as an external watchdog or another controller that can perform a shutdown. The protection system must operate within the FTT. The function of the protection system must be regularly checked within the MFOT to ensure that the protection measure is effective.
A slight variation can be seen in the following figure. Here, the protection system is part of the control system. This is not entirely straightforward, as the diversity between the control system and the protection system must be taken into account.
3) independent protection system
With this architecture, the protection system makes the decision independently of the controller. The sensor is read by both the controller and the protection system.
Using a second sensor for the protection system would allow for a diverse design. However, this would require a technological and organizational separation of the control system and the protection system.
4) Automatic shutdowns
At this point, we can imagine, for example, an automatic shutdown when a certain temperature is exceeded. As soon as the temperature rises above 41 °C, the automatic shutdown is triggered. The shutdown must be regularly checked within the MFOT and must be triggered within the FTT in the event of a fault.
If two automatic shutdowns are set up in series, regular checks of the shutdown are not necessary. This solution is useful when a self-test is not readily feasible.
Designing a secure system requires a great deal of thought. It's important that these considerations be incorporated into the architecture early on to ensure system security. Common-mode errors should be considered when considering these issues, for example, when both the control system and the protection mechanism run on the same microcontroller type or the same operating system. Random and systematic errors also play a role here. If you have any questions about this topic, please feel free to contact me. Together, we'll make your system secure.
Best regards
Goran Madzar