This guide covers what a QMS for SaMD must include under FDA’s QMSR and EU MDR, how IEC 62304 fits into the quality system, and what quality leaders in SaMD organizations need to build before their first regulatory submission or notified body audit.

How FDA classifies SaMD and what it means for your QMS

FDA does not use the term “SaMD” in its regulations; it uses “device software functions” and “Software as a Medical Device” interchangeably in guidance documents. FDA’s primary policy document on SaMD risk classification is the 2019 Software Functions guidance, which applies a risk-based framework derived from the International Medical Device Regulators Forum (IMDRF) SaMD classification system.

Under FDA’s framework, SaMD is classified based on the severity of the healthcare situation it addresses and its significance to the care pathway. Higher-risk SaMD requires stronger clinical evidence and more rigorous QMS controls. A SaMD that drives clinical decision-making in a serious or critical condition — for example, a software that interprets cardiac rhythm to guide treatment decisions — faces the same QMSR requirements as a Class III implantable device manufacturer.

FDA’s QMSR (21 CFR Part 820, effective February 2026) now explicitly incorporates ISO 13485:2016, meaning SaMD companies subject to QMSR must implement a quality management system consistent with that standard. The QMS requirements apply whether the SaMD is a standalone application, a cloud-hosted service, or a module embedded in another medical device.

EU MDR requirements for SaMD quality systems

Under the EU Medical Device Regulation (EU MDR 2017/745), software that qualifies as a medical device must comply with the full MDR framework, including Annex IX quality system requirements for conformity assessment. Article 10 of the MDR requires manufacturers (including SaMD developers) to maintain a quality management system covering design and development, production, post-market surveillance, and vigilance reporting.

For SaMD under EU MDR:

• The QMS must address the full software development lifecycle, from requirements through release and post-market updates.
• Design controls must be documented in a Technical Documentation file that satisfies Annex II and Annex III requirements.
• Post-market clinical follow-up (PMCF) and post-market surveillance (PMS) obligations apply and must be managed through the QMS.
• A Notified Body audit will review QMS documentation as part of conformity assessment for Class IIa and above SaMD.

Notified body auditors reviewing SaMD quality systems consistently examine design and development documentation, software change control records, and the organization’s approach to managing algorithm updates as device changes requiring conformity assessment review.

IEC 62304 and its role in the SaMD QMS

IEC 62304 is the international standard for medical device software lifecycle processes. It defines requirements for software development planning, requirements analysis, architectural design, unit implementation and verification, integration testing, system testing, software release, and software maintenance. Both FDA and EU MDR recognize IEC 62304 as the reference standard for medical device software development.

IEC 62304 classifies software into three safety classes based on the potential harm from a software failure:

• Class A: No injury or damage to health is possible
• Class B: Non-serious injury is possible
• Class C: Death or serious injury is possible

Class C software requires the most complete documentation: software requirements, architectural design, detailed design, unit verification, integration testing, and system testing all documented with defined review and approval steps. Class A requires significantly fewer mandatory deliverables, though good practice supports documenting all classes thoroughly.

Integrating IEC 62304 lifecycle activities into the QMS means the quality system must support design controls that align with software development workflows. Change requests, version control integration, defect management, software release records, and post-market maintenance documentation all need to flow through the QMS with complete traceability.

Design controls for SaMD: what the QMS must capture

Design controls under QMSR (and ISO 13485 Section 7.3) require a defined design and development process with documented inputs, outputs, reviews, verification, validation, and transfer. For SaMD, these elements map to specific software development artifacts.

Design inputs for SaMD include clinical use cases, user needs, intended use statements, performance requirements, interface specifications, and security requirements. These must be documented in a controlled form before detailed design begins.

Design outputs include software requirements specifications, architectural design documents, source code, build configurations, and compiled software deliverables. Outputs must be traceable to inputs through a requirements traceability matrix.

Design verification for SaMD covers unit testing, integration testing, system-level testing, and performance testing against defined acceptance criteria. Test protocols and results must be documented and approved.

Design validation requires demonstrating that the SaMD performs as intended in the real-world clinical environment. For AI/ML SaMD, validation is particularly scrutinized because the algorithm’s behavior may shift over time with new data.

Design transfer for SaMD covers the processes for building, packaging, and deploying the software from development to production, including configuration management and build verification.

All of these activities must be traceable to each other and to risk management documentation in the QMS. The audit trail for design change records must be complete and recoverable.

Risk management for SaMD under ISO 14971

ISO 14971 is the risk management standard for medical devices, including SaMD. It requires a risk management process covering hazard identification, risk estimation, risk evaluation, risk control, residual risk evaluation, and overall risk/benefit assessment. The risk management file must be maintained throughout the product lifecycle.

For SaMD, hazards include software defects that produce incorrect outputs, failure to perform when needed (availability failures), security vulnerabilities that allow unauthorized access or data manipulation, and algorithm performance degradation over time. The Risk Register for SaMD must capture both use-related hazards and software-specific technical hazards.

Post-market risk management is where SaMD organizations often struggle. New software versions, algorithm updates, and security patches all require risk management review to determine whether they introduce new hazards or change the residual risk profile. Without a QMS that links software change records to risk management documents, post-market risk review becomes inconsistent.

Change control for SaMD: the challenge of software updates

Software updates present a change control challenge that has no equivalent in traditional device manufacturing. A hardware device manufacturer may release one or two new versions per year. A SaMD team may build and test dozens of software changes in the same period, each potentially requiring regulatory assessment.

FDA’s Predetermined Change Control Plan (PCCP) framework, introduced for AI/ML-based SaMD, allows manufacturers to describe anticipated types of algorithm changes and the performance testing that will verify the change stays within approved bounds, without requiring a new 510(k) submission for each change. The PCCP must be incorporated into the quality system’s change control process — every algorithm update must be checked against the PCCP to confirm it falls within the pre-approved change scope.

For non-AI SaMD, the change control process must still classify each change by its impact on safety and performance. Changes that affect intended use, add new functions, or modify risk controls require a design change review with defined approval steps. Changes that fix defects without affecting intended use may follow an expedited review path, but the classification decision itself must be documented. Using a Process Change Notification workflow for software changes keeps the record complete and traceable.

Cybersecurity requirements for SaMD quality systems

FDA’s 2023 cybersecurity guidance for medical devices (codified under Section 524B of the FD&C Act for devices submitted after March 2023) requires manufacturers to submit a cybersecurity plan and a software bill of materials (SBOM) as part of premarket submissions. The QMS must address cybersecurity throughout the software development lifecycle and in post-market surveillance.

Quality system elements for cybersecurity include:

• Threat modeling during design to identify and mitigate attack surfaces
• Vulnerability management processes for monitoring and patching known vulnerabilities in third-party components
• SBOM maintenance and update procedures
• Incident response procedures that link cybersecurity events to the CAPA system
• Post-market surveillance processes that monitor for new vulnerabilities affecting deployed software versions

Cybersecurity vulnerabilities that affect patient safety may need to be reported to FDA under Medical Device Reporting (MDR) requirements. The QMS should have clear procedures for cybersecurity event classification and escalation.

Post-market surveillance for SaMD

Post-market surveillance (PMS) for SaMD must actively monitor real-world performance to identify trends that may signal safety issues, algorithm performance problems, or usability concerns. Under EU MDR, SaMD manufacturers must establish a PMS plan before placing the device on the market and update the PMS report on a defined schedule.

PMS data sources for SaMD typically include user-reported issues, customer support tickets, adverse events, app store reviews, sales and usage analytics, and post-market clinical data. These inputs must feed into a formal review process that evaluates whether the benefit-risk profile of the SaMD remains acceptable and whether any regulatory or design actions are required.

How Cloudtheapp supports SaMD quality systems

Cloudtheapp’s QMS platform provides the design controls, risk management, change control, CAPA, document management, and post-market surveillance capabilities that SaMD organizations need in a single, configurable, FDA-validated platform. With 60+ applications and no-code configuration, quality teams can build SaMD-specific workflows that align with IEC 62304 lifecycle stages and QMSR design control requirements without manual process mapping or custom development.

The platform’s audit trail covers all quality records including design change approvals, risk management file updates, and CAPA lifecycle activities. Validation documentation is provided with every platform update, covering the SaMD organization’s QMS software validation obligations in a single package.

For SaMD companies preparing for their first FDA submission, EU MDR conformity assessment, or notified body audit, request a demo to see how Cloudtheapp supports design control traceability, risk management integration, and post-market surveillance in a validated QMS environment.

Conclusion

A QMS for Software as a Medical Device must address the full regulatory framework — FDA QMSR, EU MDR, IEC 62304, ISO 14971, and 21 CFR Part 11 — while remaining practical enough to support agile software development. Design controls, risk management, software change control, cybersecurity oversight, and post-market surveillance are the core requirements. SaMD organizations that build these capabilities into a validated, configurable QMS platform are better positioned for regulatory submissions, notified body audits, and the post-market obligations that follow device clearance or certification.

This post created by and appeared first on Cloudtheapp