Software as a Medical Device (SaMD) describes software that performs a medical purpose on its own, without being part of a hardware medical device. A clinical decision support tool that recommends treatment dosing, an AI algorithm that reads diagnostic images, a mobile app that classifies skin lesions: all of these fall within the SaMD definition.
Building a quality system for SaMD is materially different from building one for hardware devices. The software development lifecycle introduces compliance challenges that hardware-focused quality teams may not have encountered before. This guide covers the core regulatory requirements and practical steps for building a quality system that satisfies both FDA and EU MDR expectations.
<h2>How regulators define SaMD</h2>
The International Medical Device Regulators Forum (IMDRF) definition, which both FDA and EU regulators have adopted, describes SaMD as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."
The IMDRF also developed a risk framework that classifies SaMD based on two factors: the seriousness of the situation the software is used in, and the significance of the information the software provides to the decision-making process. This 4-category framework (I through IV) maps to how aggressively regulators scrutinize the software.
Under FDA's framework, higher-risk SaMD requires more rigorous premarket review. Lower-risk SaMD, particularly software that supports clinical decision-making without replacing clinical judgment, may qualify for enforcement discretion or clearance through the 510(k) pathway.
<h2>FDA requirements for SaMD under QMSR</h2>
Under the QMSR regulation (21 CFR Part 820, effective February 2026), FDA harmonized its quality system requirements with ISO 13485:2016. This means SaMD manufacturers subject to FDA oversight must maintain a quality management system that includes:
<ul>
<li><strong>Design controls</strong> — Software design and development must follow a documented lifecycle process with defined inputs, outputs, verification, validation, and transfer requirements</li>
<li><strong>Risk management</strong> — ISO 14971-aligned risk management throughout the software lifecycle, including post-deployment monitoring</li>
<li><strong>Document control</strong> — Controlled procedures for software requirements, architecture, code review, testing, and release documentation</li>
<li><strong>CAPA</strong> — A corrective and preventive action process capable of handling software defects, algorithm performance issues, and post-market adverse event findings</li>
<li><strong>Post-market surveillance</strong> — Ongoing monitoring of software performance in clinical use, including complaint handling and MDR reporting where applicable</li>
</ul>
FDA has also issued specific guidance for AI/ML-based SaMD (the 2021 Action Plan and subsequent draft guidance), which introduces the concept of a Predetermined Change Control Plan (PCCP). A PCCP allows manufacturers to predefine the types of algorithm updates they plan to make post-clearance without requiring a new submission for each update. This is particularly relevant for adaptive AI models that continue learning from real-world data.
<h2>IEC 62304: The software lifecycle standard</h2>
IEC 62304 is the international standard that defines software lifecycle requirements for medical device software. Both FDA and EU MDR reference IEC 62304 as the recognized approach for software development process compliance.
The standard divides software into three safety classes based on the potential severity of harm from a software failure:
<ul>
<li><strong>Class A</strong> — No injury or damage to health is possible</li>
<li><strong>Class B</strong> — Non-serious injury is possible</li>
<li><strong>Class C</strong> — Death or serious injury is possible</li>
</ul>
The software safety class determines which IEC 62304 lifecycle processes apply. Class C software requires the most complete documentation, including full unit-level testing traceability and anomaly resolution records.
For AI/ML-based SaMD, the classification question is complicated by the fact that algorithm outputs may be probabilistic rather than deterministic. A model that occasionally produces incorrect outputs must be analyzed for the worst-case harm scenario, which often pushes AI diagnostics into Class C.
<h2>EU MDR requirements for SaMD</h2>
Under EU MDR (Regulation 2017/745), standalone software is explicitly classified as a medical device. Classification follows MDR classification rules, with Rule 11 being the primary rule for SaMD:
<ul>
<li>Software that provides information used to make decisions with diagnostic or therapeutic purposes is Class IIa or higher</li>
<li>Software intended to monitor physiological processes in real time where incorrect output could cause immediate danger is Class IIb or Class III</li>
<li>Software providing diagnosis or treatment decisions for serious conditions is typically Class IIb or Class III</li>
</ul>
Class IIa and above require notified body involvement. This means a technical file that includes IEC 62304 compliance evidence, ISO 14971 risk management documentation, clinical evidence, and post-market surveillance plan.
A key EU MDR requirement for SaMD is the inclusion of algorithm validation evidence in the technical file. For AI/ML software, this includes training and validation dataset descriptions, model performance metrics, and evidence that the software performs as intended across the intended use population.
<h2>Quality system requirements specific to AI/ML SaMD</h2>
AI/ML-based SaMD introduces quality system challenges that do not exist for conventional deterministic software:
<h3>Algorithm transparency and explainability</h3>
Regulators increasingly expect documentation of how an AI model reaches its outputs, particularly for high-risk applications. This does not require full mathematical interpretability, but it does require clear documentation of the model architecture, the training data characteristics, and the known limitations of the model's performance in specific populations or use conditions.
<h3>Dataset governance</h3>
Training and validation datasets are a regulated component of the AI/ML SaMD quality system. Your quality documentation should describe how datasets were sourced, how bias was assessed, how data quality was verified, and how dataset splits were performed to prevent data leakage.
<h3>Performance monitoring post-deployment</h3>
Unlike hardware devices, AI/ML models can degrade in performance as clinical practice patterns or patient populations shift over time. FDA's AI/ML action plan and EU MDR both expect manufacturers to define performance metrics they will monitor in post-market use and establish thresholds that would trigger a corrective action or regulatory notification.
<h3>Change control for algorithm updates</h3>
Every material update to an AI/ML model, whether a retrained version or a change to the inference pipeline, must go through your change control process. If the change falls within a pre-cleared PCCP (for FDA-cleared devices), it may not require a new submission. If it does not, a new 510(k) or De Novo submission may be required. Document your change control rationale for each update.
<h2>Building the SaMD quality system: practical steps</h2>
<h3>1. Classify your software before designing your QMS</h3>
Your FDA device classification, EU MDR risk class, and IEC 62304 software safety class determine the documentation requirements you need to satisfy. Get these classifications documented and justified before spending resources building processes that may be more or less stringent than required.
<h3>2. Align your SDLC with IEC 62304</h3>
Map your software development lifecycle to the IEC 62304 processes required for your safety class. For Class C software, this includes: software development planning, requirements analysis, architectural design, detailed design, unit implementation and testing, integration and integration testing, system testing, and software release.
Each phase requires documented inputs, outputs, and verification evidence. If your current development process does not produce these artifacts, add them now before you need them for a submission or audit.
<h3>3. Integrate risk management from the start</h3>
ISO 14971 risk management for SaMD must address software-specific hazards including algorithm failure modes, cybersecurity vulnerabilities, use errors arising from interface design, and failure of third-party components or cloud services the software depends on. The <a href="https://www.cloudtheapp.com/glossary-risk-register/">risk register</a> for a SaMD product should be updated at each development phase as new design decisions introduce new hazard scenarios.
<h3>4. Build post-market surveillance for software-specific signals</h3>
Your post-market surveillance plan for SaMD should capture user complaints related to software behavior, algorithm performance issues, unexpected outputs, and cybersecurity incidents. Define the collection mechanism, the review frequency, and the threshold that triggers a formal CAPA or regulatory action.
<h2>How an eQMS supports SaMD compliance</h2>
SaMD quality systems require tight integration between design controls, risk management, software change control, validation records, and post-market complaint management. Managing these in separate systems makes traceability difficult to demonstrate and audit trails difficult to maintain.
An electronic QMS that integrates design controls, <a href="https://www.cloudtheapp.com/glossary-risk-register/">risk register</a> management, CAPA, document control, and complaint handling in a single platform makes compliance more tractable for SaMD teams.
Cloudtheapp provides a fully validated, AI-powered eQMS with 60+ applications purpose-built for regulated industries including medical device, pharmaceutical, and biotech. With design controls, risk management, validation, and CAPA built to QMSR and ISO 13485 standards, Cloudtheapp helps SaMD teams maintain the traceability and documentation integrity that both FDA and EU MDR require.
<a href="https://www.cloudtheapp.com/demo/">Schedule a demo</a> to see how Cloudtheapp supports SaMD quality system requirements in practice.
<h2>Related reading</h2>
<ul>
<li><a href="https://www.cloudtheapp.com/ai-in-gxp-systems-fdas-2026-expectations-when-your-qms-uses-artificial-intelligence/">AI in GxP Systems: FDA's 2026 Expectations When Your QMS Uses Artificial Intelligence</a></li>
<li><a href="https://www.cloudtheapp.com/21-cfr-part-820-vs-qmsr-what-changed-and-what-stayed-the-same/">21 CFR Part 820 vs QMSR: What Changed and What Stayed the Same</a></li>
<li><a href="https://www.cloudtheapp.com/medical-device-qms-the-complete-guide-to-fda-qmsr-and-iso-13485-compliance/">Medical Device QMS: The Complete Guide to FDA QMSR and ISO 13485 Compliance</a></li>
</ul>
