CriTech Research, Logo Contact us for a Free Project Analysis - Email Button

We are a Veteran-Owned Firm.

Request IV&V


Equipment on a net.

Software Safety

Safety is one of the most important aspects of medical software engineering. CriTech Research performs rigorous testing and development in order to identify safety hazards and reduce risks associated with using your product.

What Is Safety Engineering?

Safety engineering is a process used to determine how a device or system can cause hazards to occur and then reducing the risks to an acceptable level. The steps involved consist of:

(1) The Developer of the System Determining What Could Go Wrong with the Device
(2) Determining How the Effects of the Failure Can Be Mitigated
(3) Implementing & Testing Mitigations

Hospital Equipment

System Level

The system analysis starts at the system level and includes device, patient, operator, and environmental hazards. Once the hazards are determined and the risk assessment (with predefined quantitative definitions) is assigned, the hazards can be assigned to software and/or hardware as appropriate.

Software Level

Software hazards are broken down into a fault tree, which is a top-down tool used for determining the functions that cause — and those that mitigate — the associated hazards. At the end of the fault tree analysis, the safety engineer needs to show the risk is lower due to the mitigations in place. The mitigations must be testable in order for the developer to demonstrate to the FDA that they have installed the mitigation and it is effective.

Performing Software Safety Engineering

There are several methods available for performing the hazard analysis. The most common types are failure mode and effects analysis (FMEA) and fault tree analysis (FTA). Since the FMEA method does not have a meantime between failures (MTBF), CriTech has found the FTA method to be superior for software safety analysis.

Levels of Risk

CriTech uses a three-range process for determining acceptable levels of risks. The three ranges are Acceptable, ALARP, and Unacceptable, which are defined below:

ALARP (As Low As Reasonably Possible) — The risks associated with the ALARP range are of the type which the developer should lower the risk as far as reasonable with management input. The cost of lowering these risks needs to be weighed against the cost of leaving the risk as it is.
Acceptable — The risk is low enough that no further mitigation is required. Generally, the acceptable range has a very low probability of occurrence and also does not have a severe hazard associated with it.
Unacceptable — All risk factors in the unacceptable range must be mitigated into at least the ALARP region. If any hazards are still in this range at the end of the project, they must be listed as safety concerns in the final hazards report. The management of the company selling the product needs to include an explanation as to why it is left in the unacceptable region to the FDA.

Proven Processes

The determination of how faults can occur requires an individual or team of people with extensive experience in the development of similar types of systems such as real-time embedded systems, PC systems, workstations, or other like processes. CriTech Research uses a structured process for the development of software, which greatly enhances the ability of the safety engineers in the performance of safety engineering.

We specialize in software verification and validation for medical devices.