IEC 62304 in Practice: Medical Device Software Development and Documentation

Why IEC 62304 Matters for Medical Device Software

Software has become a central element of modern medical devices. It controls device functions, processes measurement data, supports diagnostic decisions, and enables connected medical applications. As software becomes more complex and more integrated into medical devices, the impact of software failures on patient safety and product performance increases.

For this reason, medical device software development requires a structured and controlled approach. Unlike general software development, it is not sufficient to demonstrate that a software function works as intended. Manufacturers must provide evidence that the software was developed according to defined processes, that potential risks were evaluated, and that implemented functions meet specified requirements.

The important question is therefore not only whether the software works, but how the manufacturer can demonstrate that the software was developed safely, consistently, and according to its intended purpose.

IEC 62304 provides the framework for this approach. The standard defines processes and activities for the development and maintenance of medical device software throughout the entire software lifecycle.

IEC 62304 and the Medical Device Software Lifecycle

IEC 62304 describes the processes required to develop and maintain medical device software. The standard does not define a specific programming language, development tool, or software methodology. Instead, it defines activities, responsibilities, and required outputs that allow manufacturers to establish a controlled software development process.

The software lifecycle includes activities such as software development planning, software requirements analysis, software architecture and design, implementation, verification and validation, problem resolution, and software maintenance.

These activities create the evidence needed to demonstrate that software has been developed in a systematic way. The generated outputs are not only documents for regulatory review. They represent the relationship between product requirements, risk controls, technical decisions, implementation, and verification results.

A compliant software lifecycle is therefore not based on producing as many documents as possible. The focus is on creating a traceable development process where decisions and results can be understood throughout the product lifecycle.

IEC 62304 Software Safety Classification

An important element of IEC 62304 is the classification of software according to the possible impact of software failures on patients, operators, or other persons.

IEC 62304 defines three software safety classes:

• 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.

The classification is not determined by the amount of code, software complexity, or development effort. It depends on the possible consequences of software failures in the context of the intended use of the medical device.

Software classification is closely connected to risk management according to ISO 14971. The identified hazards, risks, and risk control measures influence the required level of development activities.

A higher software safety class generally requires more extensive documentation, more detailed reviews, additional verification activities, and stronger control of software changes.

The classification must also be maintained throughout the software lifecycle. Changes to software functionality, intended use, architecture, or risk evaluation may require a reassessment of the software safety class.

Risk Management in Medical Device Software Development

Medical device software development starts with understanding risks before implementation begins.

Risk management according to ISO 14971 identifies potential hazards, evaluates risks, and defines appropriate risk control measures. These risk controls must then be translated into software requirements.

A typical relationship between risk management and software development is:

• Risk analysis
• Risk control
• Software requirement
• Software architecture and design
• Implementation
• Verification

For example, a risk analysis may identify that incorrect input data could result in an incorrect medical decision. The required risk control may specify that the software must detect invalid input values and prevent incorrect processing.

This risk control becomes a software requirement. The requirement is then implemented through architecture and design decisions and verified through defined test activities.

The connection between risk management and software development is essential because a risk control is only effective when it is implemented, tested, and supported by objective evidence.

Medical Device Software Requirements and Design

Software requirements define the expected behaviour of the software and provide the basis for further development activities.

Requirements are typically derived from system requirements, user needs, regulatory requirements, and risk control measures.

A good software requirement must be clear, consistent, and testable. It must describe what the software needs to achieve and define measurable acceptance criteria.

Poor requirements often create problems later in the lifecycle. They can result in unclear design decisions, incomplete verification, and difficulties when assessing software changes.

After requirements are defined, software architecture describes how these requirements will be implemented. The architecture defines software components, interfaces, data flows, and responsibilities.

Detailed design describes the technical implementation of individual software components.

This step is particularly important for safety-related functions. A risk control is often not

implemented by a single software function but by the interaction of several components.

Architecture and design documentation therefore create the connection between requirements and the final software implementation.

Software Implementation, Verification and Validation

Software implementation transforms requirements and design decisions into executable software.

However, source code alone is not sufficient evidence of a controlled development process.

Depending on the software safety class, additional activities may be required, including code reviews, static analysis, coding guidelines, and unit testing.

Verification demonstrates that the software has been developed according to defined requirements.

It answers the question: Was the software developed correctly?

Verification confirms that software requirements have been implemented and that the technical results meet predefined acceptance criteria.

Validation addresses a different question: Was the right software developed for the intended use?

Validation evaluates the complete medical device in the intended environment. It considers user needs, workflows, and whether the product supports the intended clinical application.

A software function may pass all technical tests but still fail to support the actual user process.

Therefore, verification and validation are complementary activities.

Verification confirms correct technical implementation, while validation confirms suitability for the intended medical purpose.

OTSS, SOUP and Cybersecurity in Medical Device Software

Modern medical device software often contains external software components such as operating systems, libraries, frameworks, and open-source software.

These components are commonly managed as Off-The-Shelf Software (OTSS) or Software of Unknown Provenance or Pedigree (SOUP).

The manufacturer must understand which components are used, which versions are included, which software functions depend on them, and what vulnerabilities may exist.

A Software Bill of Materials (SBOM) provides transparency about included software components. However, an SBOM alone does not replace risk assessment. Each external component must be evaluated in the context of the medical device:

• Component
• Function
• Risk evaluation
• Mitigation measure
• Verification

A vulnerability in an external component does not automatically mean that the product is unsafe.

The manufacturer must evaluate the actual impact on the device, define appropriate mitigation measures, and verify their effectiveness.

OTSS management must therefore be integrated into software lifecycle activities, including risk management, change control, maintenance, and cybersecurity processes.

Software Traceability and Lifecycle Maintenance

Traceability connects the different software lifecycle activities:

• Risk
• Software Requirement
• Architecture
• Design
• Implementation
• Verification

This connection is especially important when software changes are introduced. Manufacturers must understand which requirements, risks, components, and verification activities are affected.

Traceability supports impact assessments, change control, audits, and long-term maintenance.

Software development does not end with the initial product release. Medical device software is often maintained for many years. Corrections, new functions, technical improvements, and cybersecurity updates require controlled lifecycle activities.

Each change must be evaluated to determine whether existing requirements, risks, verification activities, or validation evidence are affected.

Applying IEC 62304 Throughout the Software Lifecycle

IEC 62304 is not simply a documentation requirement. It provides a structured framework for developing and maintaining medical device software throughout the complete lifecycle.

The quality of software development is demonstrated through the connection between risks, requirements, technical decisions, implementation, verification, and validation.

A successful IEC 62304 implementation ensures that medical device software is not only functional but also developed, documented, and maintained in a controlled and traceable manner throughout the entire product lifecycle.

Disclaimer. The views and opinions expressed in this article are solely those of the author and do not necessarily reflect the official policy or position of Test Labs Limited. The content provided is for informational purposes only and is not intended to constitute legal or professional advice. Test Labs assumes no responsibility for any errors or omissions in the content of this article, nor for any actions taken in reliance thereon.