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.
|Chapter||IEC 62304 Requirement||Parasoft Solution|
|5.2||Software Requirements Analysis||Parasoft Requirements Traceability Reporting|
|5.7.4||Software System test procedures trace to software requirements||Parasoft Requirements Traceability Reporting|
|5.6||Software integration and integration testing||Integration test cases and application monitoring with Parasoft’s C/C++test|
|5.6.6||Conduct regression tests||Parasoft’s C/C++test unit testing|
|5.5.2||Software unit verification||Parasoft’s C/C++test unit testing|
|5.5.3, 5.5.4||Software unit acceptance criteria||Parasoft C/C++test Static Analysis, Metrics, Flow Analysis|
|5.7.3||Retest after changes||Parasoft’s Test impact analysis|
5.2 Software Requirements Analysis
|Requirement||Parasoft C/C++test Capability|
|Software Requirements Analysis||Reports cyclomatic complexity, essential complexity, Halstead complexity, and other code metrics|
|Use of language subset||Coding standards enforcement, e.g., detection of unsafe language constructions|
|Enforcement of strong typing||Coding standards enforcement, implicit conversions detection|
|Use of defensive implementation techniques||Enforces 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 principles||Enforcement of industry coding standards rule sets, e.g. MISRA C/C++, JSF, HIS source code metrics, etc.|
|Use of unambiguous graphical representation||Enforcement of specific formatting conventions|
|Use of style guides||Enforcement of specific coding conventions|
|Use of naming conventions||Enforcement of specific naming conventions|