Design Control Is Not a Waterfall Model

In medical device development, design control based on ISO 13485 and the FDA’s QMSR (Quality Management System Regulation) is essential. However, many developers misunderstand the design control process mandated by these regulations as a “strict waterfall model.” This article clarifies the true nature of design control according to ISO 13485 and QMSR, and explains why design control is not limited to a waterfall approach.

What Is Design Control?

Design control is a framework for systematically managing the design process of medical devices to develop safe and effective products. ISO 13485 Section 7.3 and the FDA’s QMSR (21 CFR Part 820.30) define the following elements: design and development planning, design input, design output, design review, design verification, design validation, design transfer, and design change management.

At first glance, these elements appear to suggest a sequential waterfall model. However, the existence of these elements and the necessity to implement them in a waterfall manner are entirely different matters. Regulatory requirements specify what must be accomplished, not how the development process must be structured.

Sources of Misunderstanding

Several factors have contributed to the widespread misinterpretation of ISO 13485 and QMSR design control as a waterfall process:

The waterfall diagram published in the FDA’s “Design Control Guidance for Medical Device Manufacturers” (issued in 1997) has had a significant influence. This diagram was originally reproduced from Health Canada and represented the common explanation method of that era, but it has led to the erroneous interpretation that “the FDA requires waterfall development.”

Additionally, the sequential nature of documentation creation (design input → design output → verification) and the practical convenience of maintaining audit trails in a linear process have reinforced this misconception. However, these are merely implementation examples, not fundamental regulatory requirements.

The crucial point often overlooked is the guidance on concurrent engineering also included in the FDA’s 1997 Design Control Guidance, which explicitly states that the design process need not be linear.

The True Essence of Design Control

Neither ISO 13485 nor QMSR prescribe a specific development model. Rather, they establish the following fundamental principles:

Traceability Assurance Establishing traceability from requirements through implementation and verification. This is an independent requirement from the choice of development methodology.

Integration of Risk Management Risk management activities throughout the entire design process. Activities compliant with ISO 14971 must be conducted regardless of whether development follows a waterfall or agile approach.

Design Change Management Evaluation of change impacts and appropriate approvals. In particular, version control and traceability of design changes are critical regardless of the development approach.

Objective Evidence Maintenance Documentation of the rationale and results of design decisions. This requirement pertains to ensuring that supporting evidence is clearly preserved, not to prescribing the format or sequence of documentation.

The Iterative Nature of Design Verification

Understanding the design process requires recognizing that inputs at each process step are transformed into outputs, which then become inputs for the next process. Design verification is the activity of confirming that outputs meet the input requirements, and this should be performed iteratively at various stages of design and development.

Examples of staged verification activities include: unit verification of software modules against specifications, verification of component drawings against mechanical design, verification of integration results against interface requirements between subsystems, and verification of the final system against system specifications. By conducting design verification iteratively, problems can be discovered early, and rework in downstream processes can be minimized. This approach is fundamentally different from the waterfall concept of “comprehensive testing at the end” and actually represents the more effective approach that regulations expect in practice.

Staged Verification in Response to Real-World Constraints

Real-world constraints in medical device development necessitate flexibility in the design control process:

Long Lead Time for Parts and Modules Some components—particularly custom-specification electronic parts and sensors—can take months to procure. In such situations, an “intermittent” approach is necessary, where components are ordered before design finalization and verification is conducted progressively. Such approaches are implemented as documented decisions within the framework of risk management and change management.

Time Constraints for Third-Party Certification and Testing Safety testing such as UL certification and electromagnetic compatibility (EMC) testing require substantial time. It is essential to conduct advance evaluations at the prototype or subsystem level rather than waiting for final product completion. This type of staged evaluation approach is actually standard practice in the medical device industry.

Need for Parallel Development Parallel development of hardware and software, staged firmware releases, and continuous improvements to machine learning models require synchronization of multiple development streams while conducting verification activities. This approach is important for flexible implementation of design control.

To address these real-world constraints, design verification must be viewed not as a fixed point in time but as a continuous activity throughout development, implemented with risk-based prioritization. This flexible approach reflects the practical design control that ISO 13485 and QMSR envision.

Compatibility with Multiple Development Approaches

The design control principles outlined above are compatible with various development approaches—waterfall, V-model, agile, or combinations thereof. The critical factor is that the selected development approach is implemented to satisfy the four fundamental pillars of design control: traceability, risk management, change management, and objective evidence.

Integration of Agile Development with Design Control

Agile methodology can be integrated with design control in medical device development. AAMI TIR45 released its revised edition (second edition) in 2023, providing more detailed guidance on harmonizing agile practices with regulatory requirements. Practical examples include:

Incremental Design Inputs User stories and product backlogs are detailed incrementally as design inputs. Within each sprint, pairs of design input and design output are generated progressively. Acceptance criteria for stories must include not only functional requirements but also non-functional requirements such as performance, safety, and interoperability.

Continuous Design Reviews Sprint reviews serve as formal design reviews. While design control requirements mandate design reviews, their format can be adapted to agile environments.

Evolutionary Verification Verification through automated testing via continuous integration (CI). Conducting unit tests, integration tests, and system tests continuously demonstrates that verification requirements at each stage are met.

Staged Risk Analysis Risk analysis and hazard identification at each sprint. Risk assessment for newly implemented features is performed, and risk reduction activities are reflected in the design as necessary. This process is conducted in compliance with ISO 14971.

AAMI TIR45:2023 provides more detailed implementation guidance on achieving harmony between agile development and regulatory requirements, offering concrete approaches valuable to medical device enterprises.

Affinity with the V-Model

The V-model (described in IEC 62304), which is often noted to have high affinity with design control, does not necessarily need to be strictly waterfall. Iterative execution of each V-model phase yields the following benefits: early risk discovery and mitigation, distributed verification and validation activities reducing workload, and rapid feedback incorporation.

The key point of the V-model is that at each level of development (individual modules, integrated subsystems, complete system), corresponding verification and validation activities are performed. This can be realized not only through linear approaches but also within iterative improvement cycles.

Practical Implementation Approach

Key points for flexible implementation of design control in medical device development are as follows:

Purpose-Focused Documentation Emphasis on traceability and clarity of rationale rather than format. What matters more is how clearly the design rationale is recorded rather than the format of documentation created.

Risk-Based Planning Adjustment of design control rigor according to product risk. Apply strict verification for high-risk features and appropriate management levels for lower-risk areas. This risk-based approach is also emphasized in revised ISO 13485 and QMSR.

Adaptive Processes Adjustment of processes based on product characteristics and development stage. Medical devices range from hardware-centric to software-centric to hybrid types, and optimal design control processes exist for each form.

Tool Utilization Using requirements management tools, ALM (Application Lifecycle Management) tools, continuous integration environments, and others to achieve efficiency and automation in the design control process. This facilitates audit compliance and enables rapid impact analysis during design changes.

Regulatory Trends and Future Directions

The FDA issued the final rule in January 2024, amending 21 CFR Part 820 to establish the QMSR (Quality Management System Regulation). This QMSR references ISO 13485:2016, and design control requirements are harmonized with international standards. The QMSR is scheduled to take effect on February 2, 2026, bringing further international harmonization to FDA medical device regulations.

For medical devices incorporating AI functions including machine learning, the principles of design control remain unchanged. In predetermined change control plans (PCCPs) and evaluation of continuous learning algorithms, the fundamental principles of traceability, risk management, and change management apply.

Conclusion

Medical device design control is based on fundamental principles that should be clarified before selecting a development approach. Regardless of which approach is chosen—waterfall, V-model, agile, or combinations thereof—satisfying the four pillars of design control (traceability, risk management, change management, and objective evidence) is the essential regulatory requirement.

The waterfall diagram presented in the FDA’s 1997 Guidance is an educational tool for explaining design control elements and their relationships; it does not prescribe the format of the development process. Rather, in modern medical device development, flexible approaches emphasizing iterative verification, parallel development accommodation, and risk-based decision-making deliver more effective and efficient design control.

Regulatory agencies and industry alike support such flexible and substantive approaches. What matters for development teams is constructing a design control process optimal for their organization’s product characteristics and development environment, while ensuring that the four fundamental principles are reliably implemented within that framework.

Key Takeaways

• Design control requirements are methodology-agnostic; they define what must be accomplished, not how to develop products
• The FDA’s 1997 waterfall diagram is a conceptual illustration of design control relationships, not a development methodology mandate
• Agile, V-model, and other iterative approaches can fully satisfy design control requirements when properly implemented
• The four pillars of design control—traceability, risk management, change management, and objective evidence—apply regardless of development approach
• Risk-based, adaptive approaches to design control implementation deliver both regulatory compliance and practical development efficiency
• Recent regulatory harmonization (QMSR in the USA, alignment with ISO 13485) reinforces the methodology-neutral nature of design control requirements