Using Vector Tools for Medical

Software Certification According to

IEC/EN 62304
White Paper | V1.1 2023-12
 Using Vector Tools for Medical Software Certification to IEC/EN 62304

Table of Contents

1 Medical Software ........................................................................................................................................................................ 3

1.1 Overview...................................................................................................................................................................................... 3
1.2 How Software is Different: A Unique Approach to Safety and Quality ................................................................................... 3

2 IEC 62304 in General .................................................................................................................................................................. 4

2.1 IEC 62304 in Relation to Other Standards................................................................................................................................. 4

3 IEC 62304 in Detail ...................................................................................................................................................................... 4

3.1 Safety Levels Classification ....................................................................................................................................................... 5
3.2 Objectives.................................................................................................................................................................................... 6

4 How Vector Tools Support IEC 62304 ....................................................................................................................................... 6

4.1 Software Unit Implementation ................................................................................................................................................... 6
4.1.1 Software Unit Acceptance Criteria ............................................................................................................................................ 6
4.2 Verify Software Integration ........................................................................................................................................................ 7
4.3 System Testing ........................................................................................................................................................................... 7

5 Conclusions ................................................................................................................................................................................ 7

2
 Using Vector Tools for Medical Software Certification to IEC/EN 62304

1 Medical Software

1.1 Overview

Software has become ubiquitous in our daily lives, with a wide range of devices, from home appliances to automotive infotainment systems,
increasingly becoming intelligent, autonomous, and interconnected. This is also true in the medical field, where software plays a crucial
role in devices such as blood pressure monitors, pacemakers, and robotic surgery equipment, illustrating its pervasive presence in modern
medicine.

Similar to sectors such as Avionics, Automotive, and Railway, software in the medical field is safety-critical. A bug or a medical device
malfunction could result in harm or even death to a patient. Due to the increasing number of recalls caused by software failures, regulatory
bodies have introduced safety standards. These standards aim to establish a framework for developing safer and more reliable medical
software.

Research in the field, including a study by D. R. Wallace and D. R. Kuhn titled "Failure Modes in Medical Device Software: An Analysis of
15 Years of Recall Data," reveals a significant increase in software-related recalls of medical devices. Between 1983 and 1991, software
failures accounted for 6% of medical device recalls documented by the FDA. This figure rose to 10% in the period from 1994 to 1996. In
response, the first quality standard, "ANSI/AAMI/SW68 Medical device software - Software Life Cycle Processes," was introduced in 2001.
This standard aimed to ensure a consistently producing high-quality, safe medical device software development process. Building upon
this, IEC 62304 was introduced in 2006, based on ANSI/AAMI/SW68, but with significant modifications. ANSI has since adopted it as a US
national standard (replacing ANSI/AAMI/SW 68) and in the EU as EN 62304.

Despite the introduction of standards, the incidence of software-related medical device recalls registered with the FDA continued to rise.
Research conducted by H. Alemzadeh, R. K. Iyer, Z. Kalbarczyk, and J. Raman, published in IEEE Security & Privacy, highlights that
between 2006 and 2011, 33.3% of recalls concerning Class I devices—those with a high risk of causing severe injury or death—were due
to software issues. These standards outline the requirements for medical device software development organiza tions but do not specify
the methods for implementing these requirements.

Software fundamentally differs from all other human endeavors, including traditional forms of engineering. Let's explore some of the reasons
behind this distinction.

1.2 How Software is Different: A Unique Approach to Safety and Quality

Ensuring safety and quality in software development diverges significantly from traditional methodologies applied in other fields. This
divergence stems from the inherent complexity and scale of software projects.

Consider, for example, the development efforts behind prevalent applications such as WhatsApp, Facebook, or Instagram. When measured
in terms of person-years, these efforts dwarf those of historical masterpieces like Dante Alighieri's "Divine Comedy" or Michelangelo's
Sistine Chapel. The scale is not merely in terms of decades but potentially spans centuries, highlighting the enormity of the endeavor in
software creation.

It is helpful to contrast simple and complex systems to appreciate the unique challenges in software. Simple systems, charact erized by a
limited number of inputs and outputs, encompass most mechanical and electro-mechanical devices. Regardless of their complexity, these
systems — exemplified by vehicles such as trains, planes, and automobiles — are relatively straightforward to understand regarding their
potential states and interactions. An illustrative case is the Concorde, a predominantly analog super-sonic aircraft. Its design simplicity
ensured that its catastrophic failure in July 2000 was not due to inherent flaws but external factors.

The advantage of simple systems lies in the feasibility of exhaustively testing all possible inputs, states, and outputs. This approach enables
high confidence in estimating the Mean Time Between Failures (MTBF) and achieving desired safety levels. This methodology, known as
Product Assurance, has been the cornerstone of safety in various engineering disciplines.

However, when considering software, even a relatively small amount of code can present a combinatorial explosion in possible input,
output, and state permutations. This complexity can surpass the number of molecules in the universe, as noted by Stephen Hawking in "A
Brief History in Time." Consequently, the traditional approach of Product Assurance, relying on deterministic failure probabilities, becomes
untenable in software.

The complexity of software necessitates a paradigm shift towards Process Assurance, especially for safety-critical software. This approach
does not seek to guarantee the safety of a software product through direct calculations or exhaustive testing. Instead, it em phasizes the
continuous improvement of the software development process. Adhering to safety standards like IEC 62304 focuses on establishing a
better, more repeatable process. This method acknowledges that while achieving absolute correctness in software is impossible ,
progressively enhancing code quality through refined processes is feasible.

3
 Using Vector Tools for Medical Software Certification to IEC/EN 62304

In conclusion, software's approach to safety and quality is markedly different from that in simpler, more tangible systems. This difference
necessitates fundamentally reevaluating the strategies employed, shifting from product-centric to process-centric methodologies. Such a
shift is crucial for managing the complexities inherent in software development and ensuring the delivery of safe and reliable applications.

2 IEC 62304 in General

The objective of IEC 62304 is to specify lifecycle requirements for the development of medical device software, providing a u nified
framework for software lifecycle processes in this domain. Additionally, IEC 62304 mandates that organizations involved in medical device
software development implement a Quality Management System (QMS) and adhere to a risk management process in accordance with ISO
14971.

2.1 IEC 62304 in Relation to Other Standards

IEC-62304 IEC-60601-1
IEC-82304
Medical Device Medical Electrical
Health Software
Software Equipment

ISO-14971
Risk Management

ISO-13485 IEC-62366
Quality Systems Useability

IEC 82304: Health Software - Focuses on ensuring the safety and security of health software products intended for use on general
computing platforms. This standard is specifically applicable to products marketed without dedicated hardware. Its primary aim is to
establish requirements for producers of medical devices. The standard encompasses the entire lifecycle of health software products,
including stages such as design, development, validation, installation, maintenance, and disposal. Examples of such health software
products include Radiology Information Systems (RIS) and Laboratory Information Management Systems (LIMS).

IEC 60601-1: Medical Electrical Equipment - Contains basic safety and essential performance requirements that are generally applicable
to medical electrical equipment.

ISO 14971: Risk Management - Specifies terminology, principles, and a process for risk management of medical devices, including
software as a medical device and in vitro diagnostic medical devices. The process described in this document intends to assis t producers
of medical devices in identifying the hazards associated with the medical device, estimating, and evaluating the associated risks, controlling
these risks, and monitoring the effectiveness of the controls.

ISO 13485: Quality Management Systems - A voluntary standard containing a comprehensive quality management system for designing
and manufacturing medical devices.

3 IEC 62304 in Detail

IEC 62304, which focuses on medical device software, sets forth the lifecycle requirements for software development in this f ield and
establishes a standardized framework for the software lifecycle. This standard obligates medical device manufacturers to i mplement an
effective Quality Management System (QMS) that demonstrates their capability to develop medical software that meets customer and

4
 Using Vector Tools for Medical Software Certification to IEC/EN 62304

regulatory requirements. Additionally, IEC 62304 requires integrating a risk management process, in line with ISO 14971, into the software
development lifecycle processes.

3.1 Safety Levels Classification

Based on the potential consequences of a device failure, three safety levels are designated for every software and hardware c omponent
in a medical device:
> Class A: No possibility of injury or health damage.
> Class B: Potential for non-serious injury.
> Class C: Risk of death or serious injury.

These safety levels necessitate distinct approaches to various aspects of software management, including planning, documentation,
design, development, validation, and verification. These differing approaches are detailed in Table 1.

Software Documentation Class A Class B Class C

Must contain contents according to IEC 62304, Section 5.1. The plan’s content list increases as the class increases, but a plan is
Software Development Plan
required for all classes.

Software Requirements Software requirements specification conforming to IEC 62304, Section 5.2. The content list for the software requirements
Specification specification increases as the class increases, but a document is required for all classes.

Software architecture conforming to IEC 62304, section 5.3. Refined to software unit
Software Architecture Not Required
level for Class C.

Documents detailed design for software

Software Detailed Design Not Required
units (5.4)

Software Unit Implementation All units are implemented, documented and source controlled (5.5.1)

Define process, tests, and acceptance Define additional tests and acceptance
Software Unit Verification Not Required criteria (5.5.2, 5.5.3) criteria (5.5.2, 5.5.3, 5.5.4)
Carry out verification (5.5.5) Carry out verification (5.5.5)

Software Integration &

Not Required Integration Testing conforming to IEC 62304, section 5.6.
Integration Testing

Software System Testing Not Required System Testing conforming to IEC 62304, section 5.7.

Document the version of the software List of remaining software anomalies, annotated with an explanation of the impact on
Software Release
product that is being releases (5.8.4) safety or effectiveness, including operator usage and human factors.

Table 1: Software Documentation and Safety Levels (Classes)

The activities required for Medical Device Software, based on their Safety Classes (arranged in descending order), can be summarized as
follows:

Class C
> All required activities

Class B, same as C but

> NO detailed design
> Simpler Unit Verification

Class A, same as B but

> NO Architectural Design
> NO Unit Verification Design
> NO Integration Testing
> NO System Testing
> NO Evaluation of known Residual Anomalies

5
 Using Vector Tools for Medical Software Certification to IEC/EN 62304

3.2 Objectives

The implementation of IEC 62304's objectives varies based on the Safety Level (A, B, or C) of the medical device software. The number of
mandatory objectives required to be fulfilled changes in accordance with these Safety Levels.

A B C

Software Development 23 48 54

Software Maintenance 8 8 8

Software Risk Management 1 10 10

Software Configuration Management 7 7 7

Software Problem Resolution 8 8 8

When we talk about Software Development, Level A has 23 objectives, Level B has up to 48 objectives, and Level C has all of them (a total
of 54 objectives).

4 How Vector Tools Support IEC 62304

4.1 Software Unit Implementation

The aim is to establish strategies, methods, and procedures for the verification of software units.

4.1.1 Software Unit Acceptance Criteria

What criteria must be met for the acceptance of unit implementation according to IEC 62304?

Verify that the software unit meets all requirements, including risk control measures.
> The potential strategies for testing include Black-Box Testing, Requirement-Based Testing, and others. Tools like VectorCAST/C++
can be effectively used for these strategies, as they offer features to ensure traceability with the requirements.

Verify there are no inconsistencies or contradictions in the interface design.

> In this context, conducting a thorough review, supplemented by validation activities using modeling and simulation tools, could be a
critical step.

Verify that the software code adheres to programming procedures or coding standards.
> Vector's static analysis tool, PC-lint Plus, is highly effective for successfully carrying out these activities.

The additional criteria can be met using Vector Tools.

Additional Criteria Applicable to Vector Tools How?

VectorCAST/C++ can be used to verify the sequence of specific events, particularly

Proper Event Sequence Partially
stub calls.

Data and Control Flow Fully VectorCAST/Coupling is the tool designed for checking Data and Control Flow

VectorCAST/C++ and VectorCAST/QA can be used to check certain types of

Planned Resource Allocation Partially
resources, utilizing User code or Probe Points.

Fault Handling (error definition, isolation, Generally, VectorCAST/C++ and VectorCAST/QA can be employed for fault
Partially
and recovery) handling during unit testing.

Initialization of Variables Fully This can be easily checked with VectorCAST/C++

VectorCAST/C++ and VectorCAST/QA, using User Code or Probe Points, can

Self-diagnostics Partially
check a limited range of diagnostics.

Memory Management and Memory VectorCAST/C++ and VectorCAST/QA can be used to detect a limited range of
Partially
Overflows memory-related issues by employing User code or Probe Points.

VectorCAST/C++ and VectorCAST/QA can be utilized to test a limited set of

Boundary Conditions Partially
boundary conditions, using User Code or Probe Points.

6
 Using Vector Tools for Medical Software Certification to IEC/EN 62304

4.2 Verify Software Integration

The IEC 62304 Standard mandates that software projects verify specific aspects of software integration as outlined in the integration plan
and maintain records as evidence of this verification.

Standard Objectives Applicable to Vector Tools How?

The SOFTWARE UNITS have been The verification process is solely to ensure that the integration has been carried out in
integrated into SOFTWARE ITEMS and/or No accordance with the plan. Typically, this verification is conducted through some form
the SOFTWARE SYSTEM of inspection.

In the context of Software Integration Testing, it's important to verify that the integrated software item functions as intended. Consider the
following examples:

Standard Objectives Applicable to Vector Tools How?

Requirement-Based Testing (RBT), typically carried out using tools like

The Required Functionality of the Software Fully VectorCAST/C++ or CANoe4SW, is a common method for verifying software
functionalities.

Robustness Testing, a method used to verify Risk Control Measures, can be

Implementation of Risk Control Measures Fully
conducted using tools such as VectorCAST/C++ or CANoe.

For assessing timing and other integration and system-level aspects, CANoe4SW
Specified Timing and other Behavior Fully
and vTESTstudio are the most effective tools.

Internal and external software interfaces can be tested using VectorCAST/C++. For
Specified Functioning of Internal and
Fully software-hardware interfaces, tools like CANoe, vTESTstudio, VIO System and VT
External Interfaces
System are suitable.

Abnormal conditions in software can be tested using VectorCAST/C++, while tools

Testing Under Abnormal Conditions
Fully like CANoe, vTESTstudio, VIO System and VT System are appropriate for testing
Including Foreseeable Misuse
software-hardware interactions under abnormal conditions.

4.3 System Testing

Per the standard, manufacturers are required to develop and execute a series of tests for software system testing. These tests should
include input stimuli, expected outcomes, pass/fail criteria, and detailed procedures, ensuring coverage of all software requ irements (applies
to all classes). Furthermore, manufacturers must assess the effectiveness of their verification strategies and test procedures.

For System Testing, particularly for providing digital, analog, and power stimuli, our preferred tools are CANoe, vTESTstudio, VIO System
and VT System.

5 Conclusions
Vector provides a wide array of tools to cover all the possible requirements for V&V (Validation and Verification) activities specified in
IEC/EN 62304, including any form of testing:
> Unit Testing (Black-Box Testing, White-Box Testing)
> Requirement-Based Testing (integration with a commercial requirement tracking tool)
> SW-SW Integration Testing (Modules Integration)
> SW-HW Integration Testing (Integrating with HW devices and stimuli)
> System Testing (Testing the overall system)
> HIL (Hardware in the Loop)

As this white paper outlines, Vector tools can readily fulfill most, if not all, of the Verification and Validation (V&V) activities required by the
IEC/EN 62304 standards.

7
Get More Information

Visit our website for:

> News
> Products
> Demo software
> Support
> Training classes
> Addresses

www.vector.com