IEC 62304 in Medical Technology: Safe and Regulatory-Compliant Medical Software

Introduction

The rapid digitisation in healthcare has significantly increased the role of software in medical technology. From imaging systems to mobile health apps, software solutions are an integral part of modern medical devices. However, this development also raises higher demands for safety, quality, and regulatory compliance. The international standard IEC 62304 has become a key framework for systematically managing the entire life cycle of medical software and minimising risks.

The Importance of Software in Medical Technology

Today, software is indispensable in medicine. It enables more accurate diagnoses, more efficient therapies, and continuous patient monitoring. But the growing reliance on digital solutions also brings new challenges. Faulty software can have serious consequences. From incorrect diagnoses to life-threatening situations. Therefore, a systematic approach to development, validation, and maintenance is essential to ensure safety and effectiveness.

This is where IEC 62304 comes in. The standard describes processes for the entire software lifecycle, from planning and development to maintenance. Its goal is to ensure patient safety and regulatory compliance through clear guidelines and documentation.

What Does IEC 62304 Cover?

IEC 62304 is an international standard that addresses the complete software life cycle for medical devices. It specifies how software should be developed, tested, validated, and maintained. The standard is based on proven practices in software engineering, and integrates risk management systems according to ISO 14971 and quality management systems according to ISO 13485.

Key points of the standard IEC 62304 include:

• Process Definition: Dividing the software life cycle into phases such as planning, requirements definition, design, implementation, verification, validation, and maintenance.
• Classification: Categorising software based on a decision system (see Annex 1 of the second edition) to determine the scope of required measures.
• Verification and Validation: Verification checks if the software was built correctly (e.g., through code reviews, unit tests), while validation ensures it meets user and patient needs.
• Risk Management: Systematic identification, assessment, and control of risks to guarantee safe use.
• Documentation: Extensive documentation requirements to ensure traceability and regulatory compliance.

Verification vs. Validation: Both Are Essential

A core concept of IEC 62304 is the clear distinction between verification and validation:

• Verification: Technical checks to confirm the software was implemented according to requirements, such as code reviews, unit testing, and system testing.
• Validation: Ensuring the software meets clinical needs and can be safely used in a medical environment, through clinical studies, usability tests, and user feedback.

Both processes are necessary to ensure the safety and effectiveness of the software. Verification uncovers technical flaws, while validation confirms that the software functions correctly in real-world application.

Effort and Benefits of Implementing IEC 62304

Implementing IEC 62304 requires significant resources: documentation, testing, training. However, this effort pays off by improving product quality, reducing risks, and facilitating market access over the long term. The standard also simplifies approval processes with regulatory bodies like the FDA or European authorities, as it provides systematic proof of compliance.

Furthermore, applying IEC 62304 leads to better internal processes, clearer responsibilities, and higher software quality. Manufacturers benefit from increased competitiveness and a stronger position within the regulatory landscape.

Off-The-Shelf Software (OTSS) in Medical Technology

A particular focus is on integrating off-the-shelf software (OTSS) – software not specifically developed for the medical device but obtained from third-party vendors. Examples include operating systems, frameworks, or databases.

Challenges with OTSS:

• Risk Management: Conducting comprehensive risk analyses for OTSS to identify potential vulnerabilities.
• Requirement Specification: Defining clear requirements to ensure OTSS performs its functions safely.
• Verification and Validation: Demonstrating the suitability of OTSS via tests or supplier documentation.
• Change Management: Controlling updates and modifications to OTSS, as they may introduce new risks.
• Supplier Management: Selecting and monitoring suppliers to maintain software reliability and safety.

Important: Mishandling OTSS can lead to serious consequences: product recalls, regulatory issues, damage to reputation, or patient harm.

Future Development: IEC 62304 Second Edition (2026)

The standard is undergoing a major revision, expected to be published in August 2026.

The second edition introduces important updates:

• Simplified Risk Classification: Replacing the previous three safety classes (A, B, C) with two “Software Process Rigor Levels” (I and II) to streamline risk management.
• Broader Scope: Including not only embedded software but also health software like apps and AI/ML-based systems.
• Rules for AI: Introducing specific guidelines for developing, testing, and monitoring AI-based systems, such as through the “AI Development Life cycle” (AIDL).
• Focus on Purpose: Increasing transparency about the intended use of software to better manage risks.
• Clearer Boundaries in Maintenance and Development: Clarifying distinctions between updates and rebuilds.
• Reduced Direct References to ISO 13485 and ISO 14971: Encouraging companies to develop their own quality and risk management systems.

These updates respond to technological advances, especially in AI, and aim to keep the standard aligned with current industry needs.

IEC 82304-1: The Standard for Stand-Alone Software and Health Apps

Alongside IEC 62304, IEC 82304-1 is gaining importance. It is a standalone standard concerning stand-alone software and health apps, regardless of whether they are officially certified as medical devices.

Main features:
• Scope: Covers software that operates independently, such as health apps, mobile applications, or software for health management.
• Life cycle: Requires independent validation, including risk analysis, testing, and documentation.
• Integration with IEC 62304: Builds on IEC 62304 requirements but is more comprehensive, also addressing software outside embedded medical devices.
• Regulatory Significance: While not fully harmonised yet, IEC 82304-1 is expected to be harmonised from 2024.

Distinction between IEC 62304 and IEC 82304-1:
• IEC 62304 primarily focuses on embedded software within medical devices.
• IEC 82304-1 targets stand-alone software operating independently.

Endnote

Developing safe medical software demands a systematic, standards-based approach. IEC 62304 is the main standard for software embedded in medical devices, while IEC 82304-1 focuses on stand-alone health software. Both standards complement each other and are essential for regulatory approval and quality assurance.

The planned revision of IEC 62304 in 2026 will enhance guidance on AI, ML, and health software, aligning the standard with technological developments. Manufacturers should proactively adopt these updates to develop innovative, safe, and compliant solutions.

Finally, understanding the differences between these standards and applying them correctly in each context is crucial to minimising risks, ensuring product quality, and facilitating market entry. In the evolving digital medicine landscape, IEC 62304 provides a foundational framework for responsible and safe use of modern technologies in the interest of patient safety.

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.