IEC 62304 Hazard Analysis Demystified

The most critical part of IEC 62304 compliance is the Risk Management Process.  Indeed, safety of the software is the point of the standard.  But the IEC 62304 Risk Management Process lists different requirements than ISO 14971 hazard analysis.  The specification assumes you have done an ISO 14791 analysis, and wants some additional work done for software. I have seen a lot of confusion when it comes to doing it and I think the source of confusion generally comes from trying to reconcile it with the ISO 14971 hazard analysis.

Instead, of a top-down analysis, look at the IEC 62304 software risk management more like an FMEA (failure mode effects analysis). Like an FMEA, you have to go through all the decomposed parts of the software (software items), and ask the question of what hazardous situation could occur if it failed?  Assume the worst - for example inopportune software hang due to memory corruption, or bug in a critical point.

But before we go there, let’s get a couple of IEC 62304 concepts under our belt.

• Probability of Failure - Unlike your standard ISO 14971 analysis, you can’t lower the risk by saying the probability is low.  You have to assume 100% probability for software failure.   And IEC 62304 makes the severity calculation simple - Class A, B, or C before mitigation.  
• Software Item -  There is flexibility of interpretation of what a software Item is - somewhere in the decomposition of the system’s software between the unit and the whole thing.  I personally like to look at the logical software components. This makes the process logical,  manageable, and not reliant on the implementation of code files.
• SOUP (Software of Unknown Provenance) - Don’t forget to evaluate software such as the Operating System, or libraries used.
• Software Class - A,B,C. based on the potential harm that can be done. Software mitigation cannot lower the “class” of the software.  For example, class C software cannot be reduced to class B with extra software.  Hardware however, can reduce the class.

The crux of the IEC 62304 risk management process is to provide traceability from your hazardous situations to a risk control measure, when the cause is software.  Looking at the ISO 14791 system hazard analysis, hazardous situations have been identified.  Now we have to document the potential  software items that could cause them, causes and risk control, which is often a new software requirement.

Below are simple example table entries providing the traceability

Note there is no requirement to quantify the severity of the hazardous situation here, as that is presumed done in the system ISO 14971 documentation.  That severity should drive to which class the item belongs.  

I list the new requirement as the verification to avoid duplication.  Clause 5.1.1 requires traceability between all  requirements and their test case, so by listing the requirement, and having your requirements trace matrix, you have the verification needed.

‍

Read more about industry insights and updates and visit Promenade Software's blog for more articles on the FDA & IEC 62304 software documentation.