IEC 62304 Compliance with Parasoft

IEC 62304 Software Development and Testing with Parasoft

The IEC 62304 Standard provides a framework for software life cycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. It enforces traceability and repeatability of the development and maintenance process. The US FDA accepts IEC 62304 compliance as evidence that medical device software has been designed according to the required regulations/standards. The initial version of the standard was released in 2006 and introduced a set of processes and activities for medical device software lifecycle, which are defined in the following chapters of the standard:

  • 5.1 Software development planning
  • 5.2 Software requirements analysis
  • 5.3 Software architectural design
  • 5.4 Software detailed design
  • 5.5 Software unit implementation and verification
  • 5.6 Software integration and integration testing
  • 5.7 Software system testing
  • 5.8 Software release

Standard introduces different measures to assure proper software design, implementation, and testing depending on the possible effects of the software failure on the patient.

As the standard states:

"The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a HAZARD (being a potential source of Harm) to which the SOFTWARE SYSTEM can contribute."

Manufacturers are obliged to classify the system being built with one of the three safety classes. IEC 62304 introduces three classes for for software safety levels:

  • Class A: No injury or damage to health is possible
  • Class B: Non-serious injury is possible
  • Class C: Death or serious injury is possible

IEC 62304 Amendment 1:2015

On June 15, 2015, the IEC published Amendment 1:2015 to the IEC 62304 standard Medical device software – software life cycle processes. The two most important changes introduced by amendment over the initial edition from 2006 are detailed below.

New approach to safety classification

Out of all the changes introduced, the new approach to safety classification is the most important one. The IEC 62304:2015 Amendment 1 section 4.3 point a) now reads:

"a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the RISK of HARM to the patient, operator, or other people resulting from a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute in a worst-case scenario as indicated in Figure 3."
Software item separation and handling of legacy software

With amendment 1 of the standard, system developers have higher flexibility in defining the system architecture and balancing the software quality efforts between components that are critical and less critical. The following section from the standard recommends dividing software into smaller partitions and segregating them depending on associated risk:

“The software ARCHITECTURE should promote segregation of software items that are required for safe operation and should describe the methods used to ensure effective segregation of those SOFTWARE ITEMS”

In effect, system developers can focus their compliance efforts on the parts that are critical and safe significant amount of time. Without separation, the principles of the standard related to part of a highest risk level would need to be applied to entire source code base. In the initial version of the standard, hardware related segregation was the only option given as an example, and many organizations assumed that this was the only option available. Amendment 1 clarifies it and paves the way for using software based separation.

Although the IEC 62304 provides high-level recommendations for what a compliant software development process should look like, it lacks practical guidelines on how to actually achieve this. Companies that try to implement the standard typically spend a lot of time studying it and trying to re-invent their development process in a way that they believe is compliant. In many cases, this results in excessive paperwork and numerous documents maintained in word processors or spreadsheets. This adds a considerable amount of overhead to the development process often overwhelming developers, who are already struggling to manage, integrate, and maintain an assortment of internally developed scripts and a wide range of tools (open source as well as commercial).

How Parasoft can help you with IEC 62304 compliance

Achieving compliance with IEC 62304 requires building solid software development and testing processes that are supported with multiple tools. In case of verification and validation work, organizations need a solution that include multiple testing methodologies as there is no one single technique that can lead to compliance.

ChapterIEC 62304 RequirementParasoft Solution
5.2Software Requirements AnalysisParasoft Requirements Traceability Reporting
5.7.4Software System test procedures trace to software requirementsParasoft Requirements Traceability Reporting
5.6Software integration and integration testingIntegration test cases and application monitoring with Parasoft’s C/C++test
5.6.6Conduct regression testsParasoft’s C/C++test unit testing
5.5.2Software unit verificationParasoft’s C/C++test unit testing
5.5.3, 5.5.4Software unit acceptance criteriaParasoft C/C++test Static Analysis, Metrics, Flow Analysis
5.7.3Retest after changesParasoft’s Test impact analysis

5.2 Software Requirements Analysis

RequirementParasoft C/C++test Capability
Software Requirements AnalysisReports cyclomatic complexity, essential complexity, Halstead complexity, and other code metrics
Use of language subsetCoding standards enforcement, e.g., detection of unsafe language constructions
Enforcement of strong typingCoding standards enforcement, implicit conversions detection
Use of defensive implementation techniquesEnforces defensive programming against appropriate coding standards rules, e.g., checking the return value of malloc, checking the error code value returned by called functions, etc.
Use of established design principlesEnforcement of industry coding standards rule sets, e.g. MISRA C/C++, JSF, HIS source code metrics, etc.
Use of unambiguous graphical representationEnforcement of specific formatting conventions
Use of style guidesEnforcement of specific coding conventions
Use of naming conventionsEnforcement of specific naming conventions