Guest Column | August 31, 2026

Navigating The New Era Of Design Controls For SaMDs: A Strategic Guide

By Partha Anbil, MIT Sloan Career Development Office

Innovative Healthcare Technology, Digital Interface, Analyzing Data-GettyImages-2285827921

The intersection of healthcare and software engineering has fundamentally transformed the life sciences industry. Software is no longer merely a supportive tool; it is increasingly the primary therapeutic or diagnostic agent. The rapid proliferation of Software as a Medical Device (SaMD) and artificial intelligence/machine learning (AI/ML) enabled devices has forced regulatory bodies to modernize their frameworks. For life sciences professionals, understanding the current regulatory environment is not just a compliance exercise — it is a critical strategic imperative that dictates product roadmaps, engineering methodologies, and, ultimately, market access.

This article explores the current state of design controls for software medical devices, focusing on the FDA’s recent regulatory shifts, including the Quality Management System Regulation (QMSR) transition, the integration of Agile methodologies via IEC 62304, and the evolving landscape of AI/ML regulations and cybersecurity requirements. The article draws on the latest FDA guidance, recognized consensus standards, and industry data to provide actionable insights for regulatory, quality, and engineering professionals.

The Evolution Of The Regulatory Landscape: Enter The QMSR

For decades, medical device manufacturers in the United States operated under the FDA's Quality System Regulation (QSR), codified in 21 CFR Part 820. Established in 1996, the QSR provided the foundational framework for design controls, ensuring that medical devices were designed, manufactured, and distributed to guarantee safety and efficacy. However, as the global market became increasingly interconnected, disparities between the U.S. QSR and international standards—most notably ISO 13485 — imposed significant administrative and operational burdens on multinational life sciences companies that maintained parallel quality management systems across different regulatory jurisdictions.

Recognizing the need for global harmonization, the FDA issued the final rule for the QMSR on January 31, 2024. This landmark ruling, which took full effect on February 2, 2026, fundamentally alters 21 CFR Part 820 by incorporating ISO 13485:2016 by reference. The QMSR is a concise document; most of the existing 21 CFR Part 820 text has been replaced with references to the corresponding clauses in ISO 13485. This transition represents a paradigm shift from a prescriptive U.S.-centric model to an internationally harmonized risk-based approach to quality management.1

Key Implications of the QMSR Transition

For software medical device developers, the QMSR transition carries several profound implications that touch every phase of the product life cycle. The following four areas represent the most significant operational changes for life sciences organizations.

  1. Harmonization of Design Controls: The traditional design control requirements outlined in legacy 21 CFR 820.30 are largely superseded by Clause 7.3 of ISO 13485. Organizations that maintained separate U.S. and EU quality systems now have a unified framework, reducing the cost of accessing global markets.1
  2. Evolution of Record-Keeping: The familiar acronyms (DMR, DHF, DHR) are replaced by the ISO 13485 term Medical Device File (MDF). The underlying necessity for rigorous, traceable documentation of the software development life cycle remains nonnegotiable.1
  3. Elevated Role of Risk Management: The QMSR heavily emphasizes risk-based decision-making throughout the product life cycle. The FDA considers compliance with ISO 14971 a primary way to meet the risk management requirements embedded in ISO 13485. Hazard analysis must be continuously integrated into development.1
  4. Expanded Inspection Scope: Under the legacy QSR, internal audits, supplier audits, and management reviews were exempt from routine FDA inspections. The QMSR removes this exemption entirely. Organizations must assume these internal evaluations will be scrutinized during regulatory audits.1

Bridging The Gap: Agile Methodologies And IEC 62304

A significant tension in medical device software development arises from the clash between traditional regulatory expectations and contemporary engineering practices. Historically, the FDA's design control framework was interpreted through the waterfall methodology — a linear approach that struggles to accommodate rapid iteration. Today, most software teams use Agile methodologies. Agile's iterative sprints and adaptive planning are highly effective for developing complex SaMD but initially appeared incongruent with documentation requirements.

The Acceptance of Agile in Regulated Environments

The regulatory consensus has shifted to acknowledge that Agile methodologies can enhance software safety by surfacing defects earlier. The critical standard governing this space is IEC 62304. Crucially, IEC 62304 dictates what outputs must exist, not how they are produced. It requires documented life cycle activities, rigorous traceability, and integrated risk management but does not mandate a waterfall approach.2

To bridge the gap between Agile practices and regulatory requirements, AAMI published TIR45:2023. In May 2025, the FDA officially added AAMI TIR45 to its list of recognized consensus standards, providing authoritative validation that Agile methodologies are compatible with FDA design controls.2. Furthermore, IEC 62304 Edition 2 explicitly acknowledges CI/CD pipelines and automated testing as acceptable evidence-generation mechanisms.

Implementing the Hybrid Agile Model

In practice, the most successful life sciences organizations employ a hybrid Agile model. This approach nests Agile sprints within formal waterfall-style phase gates. High-level planning, system-level verification, and formal design transfer occur at defined milestones, while iterative development lets teams run two- to four-week sprints, each producing a verified, traceable increment of software.2

To maintain compliance, organizations must embed regulatory requirements into their Definition of Done. A sprint must include updated traceability matrices, unit test verification, and updates to the risk management file. Traceability must be maintained incrementally. Agile teams using this approach have demonstrated that Class B SaMD development can be completed in 10 to 14 months, compared with 18 to 24 months with a pure waterfall approach.2

Table 1: Comparison of Software Development Methodologies in Regulated Environments

The Frontier Of Innovation: Regulating AI/ML In SaMD

The most dynamic area of medical device regulation today involves AI and ML. The market for AI-enabled medical devices is experiencing explosive growth. The global SaMD market was valued at $3.83 billion in 2025 and is projected to reach $5.3 billion in 2026, while the broader AI-enabled medical device market stood at $18.9 billion in 2025 and is expected to reach $26.2 billion in 2026.3,4 By early 2026, the FDA had authorized over 1,350 AI-enabled medical devices.5

However, AI/ML models present a unique regulatory conundrum: traditional clearance assumes a static product, whereas machine learning models evolve as they are exposed to new real-world data. A model retrained on new patient populations is, in a meaningful regulatory sense, a different device.

Figure 1: Projected Global Market Growth for SaMD and AI Medical Devices (2024–2026). Source: Synthesized from industry market research reports.3,4

Figure 2: Cumulative FDA Authorizations for AI/ML-Enabled Medical Devices. Source: FDA AI-Enabled Medical Device List; industry analyses5

Predetermined Change Control Plans (PCCPs)

To resolve this tension, the FDA finalized its guidance on PCCPs for AI-enabled devices in December 2024.6 The PCCP framework allows manufacturers to pre-specify anticipated modifications to their AI models during the initial marketing submission. A robust PCCP must include three core components:

  1. Description of Modifications: a detailed description of the specific algorithmic changes the manufacturer anticipates making post-clearance (e.g., retraining on new demographic data)
  2. Modification Protocol: the rigorous methodological approach the manufacturer will use to implement, verify, and validate those changes safely and effectively
  3. Impact Assessment: a comprehensive analysis of how anticipated changes might affect the device's overall safety and performance profile6

When a manufacturer implements a change within the scope of an authorized PCCP, they are not required to submit a new 510(k) or De Novo application. This allows companies to deploy continuously learning models and iterate rapidly. For companies building AI-enabled SaMD, they should draft the PCCP during the initial architecture phase.

Total Product Life Cycle (TPLC) for AI

Building on the PCCP framework, the FDA issued draft guidance in January 2025 regarding the life cycle management of AI-enabled device software functions.6 This underscores the FDA's commitment to a TPLC approach. Submissions for AI-enabled SaMD must now rigorously document data lineage, conduct thorough bias analyses to ensure equitable performance across demographic subgroups, and establish mechanisms for real-world performance monitoring.

Furthermore, transparency is a paramount concern. Manufacturers must clearly communicate to end users when a device is operating under a PCCP and how the model's performance might evolve. This transparency obligation extends to the clinical workflow: clinicians must understand the basis for AI-generated recommendations and the model's confidence levels. The FDA's emerging framework for generative AI and large language models (LLMs) remains an active area of regulatory development.6

The Imperative Of Cybersecurity In Software Design

As medical devices become increasingly interconnected, the threat vector for cyberattacks has expanded exponentially. Cybersecurity is a fundamental component of patient safety and must be treated as a core design control activity. The FDA finalized its comprehensive cybersecurity guidance in June 2025 and reissued it in February 2026 to align with the new QMSR framework.7 This guidance codifies security-by-design principles, making them mandatory for all submissions.

The Software Bill of Materials (SBOM) Mandate

The most significant operational change introduced by the recent cybersecurity regulations is the strict requirement for an SBOM.7. An SBOM is a comprehensive machine-readable inventory of every software component used in the device, including proprietary code, third-party libraries, and open-source packages, with specific version numbers. When a critical vulnerability is discovered in a widely used library, manufacturers must instantaneously identify affected devices. Maintaining an accurate SBOM is now a nonnegotiable prerequisite for market access.

Comprehensive Security Posture Requirements

Beyond the SBOM, the FDA's cybersecurity framework requires life sciences organizations to implement a comprehensive security posture spanning the entire product life cycle. The table below summarizes the key requirements and their operational implications for software development teams.

Table 2: FDA Cybersecurity Requirements for Medical Device Software (2025/2026)

Strategic Recommendations For Life Sciences Professionals

The convergence of the QMSR, Agile development standards, AI/ML frameworks, and stringent cybersecurity mandates has created the most complex regulatory environment in the history of medical software. To navigate this landscape successfully, life sciences organizations must adopt a proactive integrated approach to compliance that treats regulatory requirements as design inputs rather than post-development constraints.

  1. Unify Quality and Engineering: Compliance must be embedded directly into the engineering workflow and the Agile Definition of Done. Cross-functional teams comprising regulatory, quality, and engineering professionals should collaborate from the earliest stages of product conception.
  2. Invest in Automated Traceability: Manual traceability matrices in spreadsheets are a liability. Organizations must invest in modern application lifecycle management tools that provide automated bidirectional traceability from user needs to test results, aiding audit readiness and design change assessments.
  3. Embrace the PCCP for AI Innovation: If your product road map includes evolving AI/ML models, begin drafting your PCCP during the initial architecture phase. Treat the PCCP as a strategic asset that enables future innovation, rather than a regulatory hurdle.
  4. Automate Security and SBOM Generation: Integrate security tooling directly into your CI/CD pipelines. Automated SBOM generation, continuous dependency scanning, and static code analysis are essential for meeting security-by-design expectations and should be configured to fail builds if vulnerabilities are detected.
  5. Conduct a QMSR Gap Assessment: Conduct a formal gap assessment against ISO 13485:2016 and QMSR requirements. Prioritize updates to risk management procedures, design control processes, and internal audit programs, as these areas have seen the most significant changes under the new framework.

Conclusion

The regulatory framework governing software medical devices is undergoing a necessary modernization. The FDA's shift toward the harmonized QMSR, recognition of Agile methodologies via AAMI TIR45, and approaches to AI/ML and cybersecurity reflect a sophisticated understanding of modern software engineering. This creates a demanding compliance environment that is globally coherent and aligned with contemporary software development.

For life sciences professionals, this landscape presents significant opportunities. Organizations that view design controls as a structured framework for building safer, innovative software possess a distinct advantage. By aligning engineering practices with regulatory expectations from the outset — embedding traceability into Agile workflows, planning AI model evolution through PCCPs, and treating cybersecurity as a design input — companies can accelerate time-to-market, reduce risks, and deliver transformative digital health technologies. Organizations leading the next decade of medical software innovation understand compliance not as a constraint but as its foundation.

References

  1. Greenlight Guru. (2026). What's left of the QSR in QMSR? Your guide to the new Part 820. Retrieved from https://www.greenlight.guru/blog/qmsr-your-guide-to-part-820
  2. MedDeviceGuide. (2026). Agile vs Waterfall for Medical Device Software: IEC 62304 Audit Evidence. Retrieved from https://meddeviceguide.com/blog/agile-vs-waterfall-medical-device-software-iec-62304-design-controls-guide
  3. Mordor Intelligence. (2026). Software As a Medical Device Market Size & Share Analysis. Retrieved from https://www.mordorintelligence.com/industry-reports/software-as-a-medical-device-market
  4. Insoftex. (2026). Medical Device Software Development in 2026: FDA Compliance, IEC 62304, and the Engineering Stack. Retrieved from https://insoftex.com/insights/medical-device-development/
  5. U.S. Food and Drug Administration (FDA). (2025). Artificial Intelligence-Enabled Medical Devices. Retrieved from https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-enabled-medical-devices
  6. Maynard Nexsen. (2026). The AI in SaMD Trifecta: What FDA's Latest Moves Mean for Your AI-Enabled Product Roadmap. Retrieved from https://www.maynardnexsen.com/publication-the-ai-in-samd-trifecta-what-fdas-latest-moves-mean-for-your-ai-enabled-product-roadmap
  7. IntuitionLabs. (2026). FDA Digital Health Guidance: 2026 Requirements Overview. Retrieved from https://intuitionlabs.ai/articles/fda-digital-health-technology-guidance-requirements

Disclaimer: The views expressed in the article are those of the author and not of the organizations they represent.

About The Author:

Partha Anbil is at the intersection of the life sciences industry and management consulting. He has over 30+ years of experience in life sciences. He is also a life sciences industry advisor at MIT, his alma mater. He held senior leadership roles at WNS, IBM, Booz & Company, Symphony, IQVIA, KPMG Consulting, and PWC. Anbil has consulted with and counseled health and life sciences clients on structuring solutions to address strategic, operational, and organizational challenges. He is a diplomat/fellow at MIT CSAIL. He is a healthcare expert member of the World Economic Forum (WEF) and a member of the IBM Industry Academy, a highly selective group of professionals inducted by invitation only and considered IBM's highest honor.