IEC 62304 Hazard Analysis

July 4, 2016
Need help on this topic?
Contact Us

Arguably, the most critical part of IEC 62304 compliance is the Risk Management Process.  Indeed, safety of the software is the point of the standard.  The good engineering practices defined in the Development and Maintenance Processes of the standard are widely accepted as how quality software should be made.  But the IEC 62304 Risk Management Process defines a new way of looking at the hazards that software can cause.

To  do the Software Hazard Analysis, one must assume that bad things will happen in the software.  For example, a very inopportune software hang,  memory corruption, or unexpected use could occur.  Then if that happens,  what hazard can that create? Like an FMEA, you have to go through all the decomposed parts of the software (software items), and ask that question.  But before we go there, let’s get a couple of 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 pre-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 , like the FDA’s minor, moderate, and major level of concern. 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 risk management process is to provide traceability from your hazardous situations to a risk control measure, when the cause is software.  Looking at the system hazard analysis,  hazardous situations have been identified.  Now we have to document the potential  software causes and risk control.

Below are simple example table entries providing the traceability.

iec62304table.jpg

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.

Frances Cohen

Frances Cohen is president of Promenade Software Inc., a leading software services firm specializing in medical device and safety-critical system software. Frances has more than 20 years of experience leading software teams for medical device software. Starting with heart defibrillators for Cardiac Science  and following with  Source Scientific LLC and BIT Analytical Instruments Inc., Frances has overseen dozens of projects through development and the FDA, including IDEs, 510(k)s, and PMAs.   Frances has a B.S. in computer engineering from the Technion, Israel Institute of Technology.

About Promenade Software

Promenade Software, Inc. specializes in software development for Medical Devices and other safety-critical applications.

Contact

Promenade Software, Inc.
16 Technology Drive,  Suite 100
Irvine, CA 92618 
U.S.A.
info@promenadesoftware.com
(949) 329-8570
Go to Contact Form