In today’s era of agile development, DevOps, and rapid iteration cycles, many developers see IEC 62304 as a remnant of an older time. Its classical software lifecycle and reliance on the V-model often feel at odds with flexible, fast-paced development practices.

But IEC 62304 was never meant to be a rigid prescription of how software must be built. Instead, it offers a robust framework for demonstrating control, safety, and traceability—foundational elements that are critical regardless of whether your team operates on two-week sprints or longer waterfall cycles.

Traceability: The Non-Negotiable Principle

At the heart of IEC 62304 lies the concept of traceability. This includes:
-    Defined and testable software requirements,
-    Documented architecture and design decisions,
-    Aligned and recorded verification activities,
-    Integrated risk control measures per ISO 14971,
-    Management of software anomalies and configuration changes.
These principles apply universally—whether your team uses Scrum, Kanban, or any hybrid agile framework.

IEC 62304 and Agile: Compatible by Design

While IEC 62304 promotes a structured lifecycle, it is fundamentally methodology-agnostic. Agile development can align with its expectations when interpreted through the lens of outcomes and artifacts rather than rigid sequencing.

Sprints can deliver incrementally tested components; backlogs can map to requirements specifications. The key is that all lifecycle activities—from requirements through verification—are documented, reviewed, and controlled.

What matters is not how you build your software, but how well you can demonstrate that it’s safe, effective, and meets regulatory expectations.

Rethinking the V-Model as a Documentation Scaffold

The V-model, often seen as synonymous with IEC 62304, should not be taken as an instruction manual for development processes. Instead, it is best understood as a documentation scaffold - a visualization of the alignment between development activities and their corresponding verification.Agile development fits this model when:

- Requirements trace to test cases,

- Design decisions are validated,

- Code changes are controlled and reviewed,

- Releases are documented with corresponding risk assessments.

Alignment with Regulatory Expectations

Regulatory bodies continue to recognize and rely on IEC 62304, not for its lifecycle structure, but for its consistent, auditable expectations:

High level requirements, as indicated in Annex II - Medical Device Regulation (MDR 2017/745) may be traced to more software specific requirements indicated by IEC 62304, such as requirements, risk management, and configuration control, software version history, and risk-based verification which are naturally supported by IEC 62304’s framework. Even the FDA’s 2023 Guidance on software documentation directly maps back to IEC 62304 concepts.

What regulators want is assurance that manufacturers understand their software, can verify its behavior, and can mitigate its risks. IEC 62304 remains the most globally harmonized way to provide that assurance.

As a Notified Body under MDR, DQS-MED continues to recognize IEC 62304 as the most suitable standard for structured documentation of medical device software lifecycle processes.

Conclusion: IEC 62304 is a Standard worth Reinterpreting

IEC 62304 is not a relic of the past—it’s a regulatory anchor for modern software development.

Yes, IEC 62304 needs to be reinterpreted, or even adapted for the realities of today’s development environments. Its lifecycle model may appear traditional, but its principles—traceability, verification, and control—are timeless.

In fact, as we adopt more agile, flexible development strategies, those principles become even more critical for medical device software developers who want to ensure not only compliance, but patient safety.

Compliant Software Starts Here — MDR, ISO 13485, MDSAP and more by DQS!

Author

Dr. Andrei Ninu

Dr. Andrei Ninu is a highly experienced regulatory expert specializing in active medical devices, with a strong focus on functional and software safety as well as artificial intelligence (AI) applications in healthcare. He has extensive expertise in EU regulatory compliance, particularly in certification and conformity assessment processes for medical device manufacturers.

Beyond his regulatory expertise, Dr. Ninu brings over a decade of hands-on experience in software development, having witnessed firsthand the evolution of AI systems in healthcare and their transformative impact on medical technology.

His academic background includes a Master’s degree in Control Systems and Robotics and a PhD in Computer Science/Biomedical Engineering from the Vienna University of Technology, where he focused on human-machine interaction in rehabilitation. He further advanced this field during his postdoctoral research at the University Medical Center Göttingen, specializing in robotic-assisted rehabilitation.

Choose your country or language

IEC 62304 is Not Obsolete - It’s a Traceability Framework for Modern Medical Software Development

Dr. Andrei Ninu

Traceability: The Non-Negotiable Principle

IEC 62304 and Agile: Compatible by Design

Rethinking the V-Model as a Documentation Scaffold

Alignment with Regulatory Expectations

Conclusion: IEC 62304 is a Standard worth Reinterpreting

Compliant Software Starts Here — MDR, ISO 13485, MDSAP and more by DQS!

DQS Newsletter

Dr. Andrei Ninu

You Might Also Enjoy These Reads

AI in Medical Devices: Meeting EU Compliance with AI Act and MDR

UK PMS Regulations for Medical Devices: Part 3 – UK PMS Regulations vs. EU MDR

UK PMS Regulations for Medical Devices: Part 2 – Vigilance & Reporting Requirements

Any Questions?