In medical technology, technical errors in a device can have fatal consequences for operators or patients. Therefore, a safety architecture is generally required during the approval process for medical devices. It is important to address the issue of functional safety right from the product design stage. The goal of functional safety considerations is to design medical devices in such a way that technical errors can be detected early and any hazards resulting from the respective error can be eliminated. In this blog post, I would like to use a simple example to demonstrate how such a safety architecture can be created for a medical device.
Info: based on a previous Blog article If you haven't already, you should familiarize yourself with the terminology used in this article. The article also describes the theoretical foundations behind functional safety and lists the standards relevant to us as medical technology developers.
The example
We'll focus on the simplest possible example, one that everyone has probably used before (or at least knows ;-)): an inhaler for inhaling saline solutions to cleanse the airways. This example is purely illustrative, so I deliberately make no guarantees regarding completeness or functionality (or feasibility).
Step 1: Understand the concept & (if applicable) requirements
The concept tells us which basic components the system should consist of. First, the electrical components are listed:
- Control unit (microcontroller)
- heater
- Electronic switch for switching control (MOSFET)
- NTC temperature sensor
- Control panel:
- LCD display for displaying target and actual temperature
- Rotary knob for setting the target temperature
- Solenoid valve to control the solution flow into the boiler
- Rocker switch for turning the device on and off
- Power supply to provide the internal 24V supply voltage
Then the basic mechanical components are named:
- Housing
- Hose and mouthpiece
- boiler
- Solution reservoir
From the device concept we can also learn about the physical functioning of the inhaler:
"From the solution reservoir, the liquid flows, driven by gravity, through the solenoid valve to the boiler, where it is heated to the user-adjustable setpoint temperature (max. 130°C) and vaporizes. From there, the vapor rises into the tube, which transports it to the mouthpiece. The patient inhales the vapor through the mouthpiece."
The physical mode of operation is also captured in a block diagram:
In addition, some system requirements have already been defined:
- Req. 1: The system must regulate the boiler temperature to the setpoint temperature.
- Req. 2: The system must provide the option to adjust the boiler setpoint temperature via a control panel.
- Req. 3: The system must limit the boiler setpoint to a maximum of 130°C.
- Req. 4: The system must shut down the heater if its actual temperature exceeds 150°C.
Once we understand how the device works, what components it consists of, and how to operate it, we can move on to the risk analysis!
Step 2: Risk analysis (identification and assessment of risks)
Hazards in the sense of functional safety arise when physical and technical processes occur in an uncontrolled manner. This is the case, for example, when a device unintentionally releases excessive energy or releases toxic chemicals (or both). These hazards can pose a threat to users, patients, and the environment—for example, people in the same room as the device.
One way to collect and evaluate possible errors and risks within complex technical systems is the (System) FMEA (Failure Mode and Effects Analysis). If the risk priority number is ignored and combined with a risk acceptance matrix (see ISO 14971)This creates a tool for system-wide risk capture and assessment. Now, decisions can be made quickly and easily about where appropriate security measures should be implemented.
An extract from the risk management file (risk acceptance matrix + risk management table) could look like this for our device:
Step 3: Safe States
First, we want to look at the so-called “Safe State” This is the state in which the faulty device can no longer pose any danger. Depending on the error, several states can be considered for the safe state. When defining the safe states, it is important to weigh the consequences of the error against the consequences of the safe state. If, for example, a life-sustaining measure is interrupted due to the safe state, stopping the device is only justifiable in the case of more serious errors (e.g. acute danger to life). For less serious errors, there could then be an additional safe state in which the functionality of the device is reduced to a minimum and the user is alerted to the error via an alarm (emergency operation).
In our case, however, interrupting therapy is not a problem and we can assume that stopping therapy is the only safe state.
Step 4: Security requirements
Starting from step 2, we can identify 4 of the 5 identified risks Safety requirements that outline our security architecture. These must also be documented in the system requirements in order to later provide evidence of compliance with the requirements (validation).
- Req. 5: The system must detect a false temperature measurement and shut down the heater as a result.
- Req. 6: The system must be protected against high currents.
- Req. 7: The system must detect a failure of the switching MOSFETs and consequently shut down the heater.
- Req. 8: The system must detect a SW stall and shut down the heater as a result.
For documentation, a separate chapter in the specifications is recommended, which could be called “Safety Requirements”, for example.
Step 5: Determination of FTT and MFOT
As a reminder:
- FTT (Fault Tolerance Time) describes the time that can pass before the fault becomes a hazard.
- MFOT (Multi-Fault Occurence Time) describes the time until multiple faults occur.
The FTT must be defined individually for each fault type. The basis for determining it is the physical effects of the fault: the FTT is usually quite short! In any case, a rationale for selecting a suitable FTT should be provided, as the FTT directly influences the design of the safety measures.
For our example, the FTTs could look like this:
| Mistake | Driven | FTT | Rationale |
|---|---|---|---|
| Incorrect temperature measurement | fire, injury | 10s | The controlled system is too slow to heat up to a dangerous temperature in less than 10 seconds. This is shown by the XY calculation. |
| Switch failure | fire, injury | 10s | Reason as for falsified temperature measurement. |
| SW stable | fire, injury | 10s | Reason as for falsified temperature measurement. |
| High currents | fire | 0.5s | Short-circuit currents generate a great deal of heat, which could ignite surrounding material. This value is determined by the XY standard, which takes into account the expected short-circuit current for the selected power supply as well as the conductor thickness to the heater. |
We should also define the MFOT for our product. Often (e.g., for infusion pumps), this time is defined in the corresponding product standard. Typically, the MFOT can be assumed to be the time for a single treatment, provided it is not too long (e.g., longer than one day). This means that a self-test at device startup, which detects a potential initial error, does not need to be repeated during treatment, provided the treatment time is short enough. We will define the average usage time as the MFOT for our product: this is 20 minutes!
Step 6: Safety Measures
From the requirements we can now Measures (“Safety Measures”) that describe a concrete implementation of the requirements. All functional safety measures aim to transfer the device to the respective safe state. The architect defines the safety measures in the software, hardware, and mechanical requirements. There, they serve as the basis for the developers' implementation in the software/hardware/mechanics.
Security requirements are typically implemented in the form of runtime checks, self-tests after device startup (Power On Startup Test, POST for short), and user checks before commissioning (Pre-Operative System Checks). Duplicated measures (e.g., runtime check + POST) are often used. Pre-Operative System Checks are particularly recommended for modular systems with many decentralized, interoperable components. Furthermore, the normative specifications for the test strategy must be observed: depending on the selected security architecture, additional tests may be necessary. If, for example, an automatic shutdown is involved, this must be verified within the MFOT using a self-test.
For our system, we now select the following measures (only HW and SW requirements, here in the form of a traceability matrix):
As you can see, some sections of text in the table are marked in red. These are normative requirements (FTTs and test strategies).
Step 7: Validation
At this point, all measures have already been incorporated into requirements. Of course, it is important to verify the correct function of the measures! To do this, we need to write an adequate test specification, which can then be converted into a test report by conducting the tests! This serves, as mentioned above, as the overall proof of the functional safety of our product. You can learn how to write a good test specification in this blog article about testing.
Conclusion
The functional safety of a medical device contributes significantly to the successful approval of a medical device. Once the initial conceptual decisions regarding a product's system architecture have been made, functional safety considerations can and should be addressed, as these will directly impact the hardware, software, and mechanical design of the device. I hope this blog post has provided you with an approach to creating the safety architecture. If you have any further questions on the topic, please feel free to contact us! You can use the comment function or contact us directly via the contact button, by e-mail or call 09131/691240.