Creating Certified Medical Devices with Qt

Many modern medical devices provide a graphical interface to the user. In dialysis machines, for example, touch screen interfaces to set up the treatment parameters and to monitor the treatment progress are commonplace. Qt is a viable technical solution to implement those interfaces, so it is used in quite a number of medical devices.

When designing and implementing a medical device, however, you have to do more than to find a good technical solution. You have to analyze the risks associated with your device, and you have to make sure that your system design and development is appropriate for that risk. That is not an easy task, but there are laws, regulations and standards that provide guidance on the required development process for medical device software. Important guidance documents are:

• IEC 62304: Medical device software – Software life cycle processes
• General Principles of Software Validation; Final Guidance for Industry and FDA Staff
• Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices

If you develop software for a medical device that will be marketed in the EU and the US, you will have to follow those guidelines. They are mainly concerned with the process of designing, implementing, verifying and testing your own device software. But they also influence the use of third-party software like Qt in your device. If your third-party software, or SOUP (“Software of Unknown Provenance” in terms of IEC 62304), may contribute to a hazardous situation, i.e. might lead to harm to the patient, you have to minimize that contribution and make sure that the chosen third-party software is appropriate.

If we continue the example of a dialysis machine, one of the functions of the therapy - besides cleaning the blood of the patient - is to remove excess water from the body of the patient. Depending on the physical condition of the patient, up to four liters of water may be removed in a typical therapy session. But that is just the maximum amount, a patient might need less water removal, or none at all. The problem is that you have to enter the right amount of water to remove via the user interface, and it is critical that you do not remove more than that amount, as removing too much water might lead to a circulatory collapse and might severely harm the patient. Input of safety-critical values is a typical critical user interface function in medical devices, as well as the output of safety-critical values, e.g. the oxygen saturation of a patient’s blood.

Another critical user interface function that is common in medical devices is alarms. Imagine that during a dialysis therapy, the device detects that there is an air bubble in the blood line (which, when infused back into the patient, might lead to embolism). What the device probably should do is to stop the therapy, sound an alarm sound and display a visual warning to the operator of the device to take appropriate actions.

Obviously, if one of those functions fail to work correctly, the patient may be harmed. Now a manufacturer might ask some basic questions:

• 1. What can we do to prevent the harm to the patient?
• 2. May we use Qt to implement those safety-critical user interface functions?
• 3. Do we need a validated toolkit to build a safety-critical user interface?

Let's start with the first question. It can only be answered by performing a detailed risk analysis. The standard ISO 14971 provides guidance on how to do this. In the example of the air-in-line alarm, we start with the hazard (the air bubble), determine the potential harm (which - in the worst case - is the death of the patient) and try to estimate the probability of the harm (for the sake of the example, let's assume an air bubble once per 24 hours of treatment). If we combine those assumptions and estimates, we will find that the risk (the combination of the severity of the harm and the probability of its occurrence) is not acceptable. Thus we need to do something to reduce the risk. We might decide to add an air-bubble-detector into the system, and to add an alarm function to the user interface. When a bubble is detected, the system stops the therapy and raises the alarm to request the user to take appropriate action.

This is a reasonable first step, but not the end of our analysis. What happens if the alarm is not displayed? This could be caused by a problem with the display driver, or a failing LCD backlight, or by an unexpected failure of the GUI toolkit. A medical device needs to be safe even in the presence of a single fault in the system. So having an alarm system that might fail because of a single reason is not acceptable. Typical devices would therefore add another redundant and diverse alarm mechanism, e.g. a flashing LED that can be activated even when the GUI is not working properly. With this second channel, the alarm can be indicated even with a failure in the GUI or a failure in the LED mechanism. And this is generally considered to be safe. Of course, there is a cost - additional hardware.

There are other examples of diversity in graphical user interfaces: If we display a critical numerical value, we might be concerned that loading the correct font fails. Remember, we have to assume a first fault like a damaged font file. We can add some redundancy and display a bar graph visualizing the numerical value in addition to the number. Even if the numbers are not displayed correctly, the bar graph will present the information to the user. Sometimes you will see an old-fashioned LCD screen next to a touch screen on a medical device. This is a secure (if not pretty) way to add redundancy to the display system. The important point is that the resulting risk, even with a failure in the GUI, has to be acceptable.

Now we can tackle the second question: May we use Qt for the GUI of a safety critical medical device? Principally, the choice of technologies is up to the system designer. None of the standards will tell you to choose one toolkit over the other. The manufacturer of the medical device needs to make sure that it is safe, according to what has already been mentioned. But in addition to that, the IEC 62304 and the OTS require that we make a conscious decision about the choice third-party software or SOUP. In addition to the mentioned risk analysis, we need to make sure that:

• The toolkit provides the functionality and performance that we depend on
• The device provides the support necessary to operate the toolkit within its specification
• The toolkit performs as required for our system

So a device manufacturer will have to provide evidence of these claims, i.e. will have to document the requirements to Qt, analyze and document the requirements imposed by Qt on the system and you will have to perform some degree of testing in the system to prove the requirements are met. And the manufacturer needs to set up a monitoring process to regularly check the bug list of the third-party software component and to assess if any new bugs impose additional risks to the patients. All of these points might be subject to an audit by a notified body or the FDA.

Very often the following question will be asked: Where can we buy a GUI toolkit that has already been validated to be suitable for use in safety-critical medical devices? Unfortunately, there is no such thing as a pre-validation for medical devices. As the starting point of third-party component validation is focused on the risk analysis, only the manufacturer of the device can do the qualification, because only the manufacturer can identify the risks. Therefore, IEC 62304 and the FDA regulations do not define a certification process for third-party software (SOUP). The best way a vendor can support a medical device manufacturer therefore is by providing good documentation of its development process and proof of internal testing, which allows the manufacturer to asses if it is appropriate for the planned application.

If you use a commercial license of Qt, contact The Qt Company and request a description of the QA practices and test report of the Qt version you intent to use. These documents are readily available and support your qualification effort.

To summarize, if you plan to use Qt for safety-critical functions in a medical device, make sure to:

• 1. Identify all risks that might be caused by failures of the user interface
• 2. Try to mitigate those risks by means outside the user interface, e.g. by redundant inputs and outputs
• 3. Build redundancy into the user-interface itself to protect against single-fault failures
• 4. Carefully select the software components you use to implement the user interface
• 5. Document the rationale for your decision that Qt is appropriate for your device so it can be reviewed by external auditors

If you follow those steps, you will be able to design your device with a modern user interface, and still meet all the safety requirements.

About the Blog Post Author:

Matthias Hölzer-Klüpfel is an independent consultant, trainer and contractor concerned with development processes and project management for medical device software. He co-founded the association “International Certified Professional for Medical Software Board e.V.” which provides the foundation for a certified education program for medical device software development.

You can reach Matthias via matthias@hoelzer-kluepfel.de if you have any further questions.

Earlier Blog Posts about Functional Safety with Qt:

• Overview of Functional Safety
• Creating Certified Systems with Qt

If you are interested in hearing more about Functional Safety, there is a talk at Qt World Summit by Tuukka Turunen about 'Creating Functional Safety Certified Systems with Qt'.