QMSR for AI SaMD: De-Risking Your Cardiac AI Investment

The FDA has harmonized its Quality System Regulation (QSR) with the international standard ISO 13485, and the new Quality Management System Regulation (QMSR) is now in effect. This critical shift to the new Quality Management System Regulation (QMSR) demands strategic alignment of software development lifecycles. Companies that have not adapted their quality management systems (QMS) risk not only compliance pitfalls but also significant commercial disadvantages in a rapidly evolving regulatory field.

The FDA’s Harmonization Imperative: From 21 CFR Part 820 to QMSR

For decades, medical device manufacturers in the United States have operated under 21 CFR Part 820, the FDA’s Quality System Regulation. However, recognizing the global nature of medical device development and the increasing complexity of technologies like AI-powered SaMD, the FDA has taken a monumental step towards international harmonization. The final rule for the QMSR, published in early 2024 (89 FR 7496), formally aligns the FDA’s requirements with ISO 13485:2016, “Medical devices, Quality management systems, Requirements for regulatory purposes” FDA QMSR Final Rule. This shift is not merely cosmetic. It represents a fundamental change in how the FDA expects QMS to be structured and implemented, particularly for software-centric devices. The QMSR became effective on February 2, 2026, following a two-year transition period designed to give manufacturers time to adapt. For SaMD developers, especially those using modern AI, compliance is now mandatory. The core principle driving this change is to simplify regulatory processes, reduce redundant audits for global companies, and ensure a consistent standard of quality and safety across jurisdictions. While 21 CFR Part 820 focused heavily on manufacturing process controls, ISO 13485 provides a more complete framework that inherently lends itself to the entire product lifecycle, from design and development through post-market surveillance. This is particularly relevant for SaMD, where “manufacturing” is often synonymous with software development, deployment, and maintenance.

Integrating IEC 62304 into Your Harmonized QMS

While ISO 13485 sets the overarching QMS framework, the specific nuances of medical device software development are best addressed by IEC 62304:2006/AMD 1:2015, “Medical device software, Software life cycle processes” IEC 62304 standard. This standard is not directly harmonized by the FDA in the same way as ISO 13485, but it is widely recognized as the industry best practice for ensuring the safety and quality of medical device software. For SaMD developers, integrating IEC 62304 principles into an ISO 13485-compliant QMS is important. IEC 62304 categorizes software based on its potential to cause harm (Class A, B, or C), thereby dictating the rigor of the development, verification, and validation activities. For cloud-hosted SaMD, this means:

• Software Development Planning: Defining the software lifecycle, including requirements, design, implementation, verification, and release.
• Software Requirements Analysis: Thoroughly documenting functional and non-functional requirements, with a strong emphasis on safety and security.
• Software Architectural Design: Structuring the software to manage complexity, facilitate testing, and ensure robustness, especially for AI components.
• Software Verification and Validation: Rigorous testing at unit, integration, and system levels, including performance testing of AI algorithms.
• Software Configuration Management: Controlling changes to software items throughout the lifecycle.
• Software Problem Resolution: Establishing a strong process for identifying, analyzing, and resolving software defects.

The teamwork between ISO 13485 and IEC 62304 is undeniable. ISO 13485 provides the “what”, the requirements for a QMS, while IEC 62304 provides much of the “how” for software components. For instance, ISO 13485 requires documented procedures for design and development, while IEC 62304 provides specific guidance on how to execute those procedures for software.

Five Steps to Align Your SaMD Software Development Lifecycle with ISO 13485

The transition to a QMSR-compliant QMS, particularly for AI-powered SaMD, requires a structured approach. Here’s a five-step checklist for regulatory affairs directors, software engineering leads, and compliance officers:

1. Conduct a Gap Analysis Against ISO 13485:

Your first step is to thoroughly compare your existing QMS (likely based on 21 CFR Part 820) against the requirements of ISO 13485:2016. Pay particular attention to clauses that may have been less emphasized under the old QSR but are critical in ISO 13485. For SaMD, this includes:

• Clause 4.1.6: Validation of Computer Software: This is paramount for AI-driven SaMD, requiring validation of all software used in the QMS, and for production and service provision.
• Clause 7.3: Design and Development: Ensure your software development lifecycle is fully documented and controlled, encompassing planning, inputs, outputs, review, verification, validation, and transfer. This is where IEC 62304 becomes an invaluable guide.
• Clause 7.5.6: Validation of Processes for Production and Service Provision: For cloud-hosted SaMD, this extends to the validation of your deployment pipelines, cloud infrastructure, and data management processes.
• Clause 8.2.3: Monitoring and Measurement of Processes: Establish strong metrics and monitoring for your software development and operational processes, important for demonstrating control over AI model performance and drift.

Identify specific areas where your current QMS documentation, procedures, and practices fall short.

2. Revise QMS Documentation and Procedures

Based on your gap analysis, systematically update your QMS documentation. This isn’t just about re-titling documents. It involves re-engineering processes to meet the spirit and letter of ISO 13485. For SaMD, this includes:

• Software Development Plan (SDP): Integrate IEC 62304’s lifecycle processes directly into your SDP, detailing how requirements are managed, how design choices are made for AI components (e.g., model architecture, training data management), and how verification and validation will be performed.
• Risk Management File: Expand your risk management processes (per ISO 14971) to specifically address software risks, including algorithmic bias, data privacy, cybersecurity vulnerabilities for cloud-hosted solutions, and potential for algorithmic drift.
• Change Control Procedures: Develop strong procedures for managing changes to SaMD, including software updates, AI model retraining, and infrastructure changes. For AI/ML SaMD, this could involve establishing a Predetermined Change Control Plan (PCCP) to manage predefined modifications without requiring new premarket submissions.
• Post-Market Surveillance Plan: Detail how you will monitor the performance of your SaMD in the real world, collect user feedback, and manage corrective and preventive actions (CAPA), especially for AI model performance monitoring.

3. Implement IEC 62304 Best Practices for Software Lifecycle

As noted, IEC 62304 is the blueprint for compliant medical device software. Ensure that your software engineering teams are fully integrating its principles:

• Software Classification: Clearly classify your SaMD components according to IEC 62304’s safety classes (A, B, or C) to determine the required rigor of development and testing.
• Software Requirements Engineering: Implement formal methods for capturing, analyzing, and tracing software requirements to ensure clarity, completeness, and testability. This is especially vital for AI, where defining “requirements” for an adaptive algorithm can be complex.
• Software Verification and Validation (V&V): Go beyond basic functional testing. Implement strong V&V strategies that include unit testing, integration testing, system testing, performance testing, and cybersecurity testing. For AI, this means validating the training data, the model’s performance on unseen data, and its robustness to adversarial attacks.
• Configuration Management: Establish strict version control for all software artifacts, including source code, build scripts, libraries, AI models, and training datasets.

4. Train Your Teams and Foster a Quality Culture

A QMS is only as effective as the people who implement it. Complete training is essential:

• Regulatory Affairs: Ensure your regulatory team understands the nuances of ISO 13485 and its application to SaMD.
• Software Engineering: Train your developers, testers, and DevOps engineers on IEC 62304, secure coding practices, and their roles within the new QMS.
• Management: Leadership must champion the QMS transition, allocating necessary resources and demonstrating commitment to quality.

Foster a culture where quality and regulatory compliance are integral to every stage of the software development lifecycle, not an afterthought.

5. Prepare for External Audits and Continuous Improvement

Once your QMS is updated and implemented, prepare for external audits. This includes internal audits to identify any remaining non-conformities before a Notified Body audit (if seeking CE Mark) or an FDA inspection. Remember that a QMS is a living system. Continuous improvement is key. Regularly review your processes, collect feedback, and adapt your QMS to reflect new technologies, regulatory guidance, and lessons learned from post-market surveillance.

Conclusion

The FDA’s harmonization of 21 CFR Part 820 with ISO 13485 is a key moment for the medical device industry, particularly for developers of AI-powered SaMD. Companies that proactively adapt their quality management systems, integrating the specific guidance of IEC 62304 into their software development lifecycles, will be well-positioned for regulatory success and market leadership. The transition period is over. Those who delay risk falling behind, facing increased enforcement scrutiny, and potentially hindering their ability to bring innovative, safe, and effective AI health tools to patients. This guidance is based on the Federal Register QMSR final rule (89 FR 7496) and current CDRH guidance on software as a medical device CDRH SaMD guidance.