Software as a Medical Device (SaMD) is software intended for one or more medical purposes that achieves those purposes without being part of a hardware medical device. Defined by the IMDRF, it runs on general computing platforms, is regulated as a device, and spans diagnostic, screening, monitoring, and treatment-support functions.
What is Software as a Medical Device (SaMD)?
SaMD sits at the standalone end of medical device software. The International Medical Device Regulators Forum (IMDRF) introduced the term in 2013 to describe programs that deliver a medical function on their own, unlike Software in a Medical Device (SiMD), the embedded firmware that controls hardware such as an infusion pump. In the European Union, both fall under the broader label Medical Device Software (MDSW).
A mobile app that analyzes retinal images, a cloud algorithm that flags strokes on CT scans, and a program that calculates insulin dosing all qualify as SaMD. The software is the device, and it runs on off-the-shelf phones, servers, or virtual infrastructure, which makes its regulation distinct.
Why Software as a Medical Device (SaMD) matters in medical device development
Getting SaMD wrong carries direct patient safety consequences. A false negative can delay treatment, and a miscalculated dose can cause harm. Because the output feeds clinical decisions, regulators hold SaMD to evidence standards matched to its risk.
Classification drives everything downstream. It sets the conformity assessment route, the depth of clinical evidence, and whether a notified body or the FDA reviews the submission. Misjudge the class, and a team can build the wrong quality file, skip a required clinical evaluation, or face months of rework.
SaMD also ships new versions far faster than hardware, and each change can affect safety. Change control, versioning, and, for AI models, drift monitoring are ongoing obligations rather than one-time gates.
How Software as a Medical Device (SaMD) is classified and governed
Two frameworks anchor SaMD classification. The IMDRF model sorts SaMD into four categories, I through IV, by combining the significance of the information the software provides to a healthcare decision (inform, drive, or treat and diagnose) with the seriousness of the patient condition (non-serious, serious, or critical). Category IV is the highest risk.
In the EU, Rule 11 of EU MDR 2017/745 Annex VIII classifies standalone software from Class I to Class III on similar logic. Guidance MDCG 2019-11, revised in 2025, maps the intended purpose to a class with examples for AI-enabled and modular software. Most SaMD lands in Class IIa or higher, and genuine Class I software is now rare.
Several standards govern the build:
- IEC 62304 defines the software lifecycle, from planning through verification, release, and maintenance, with safety classes A, B, and C. A second edition expected in 2026 moves to two rigor levels and folds in AI and cybersecurity.
- ISO 14971 governs risk management, including software-specific hazards like algorithm drift and data input errors.
- IEC 62366-1 covers usability engineering, which matters when clinicians act on software output.
- IEC 81001-5-1 sets the cybersecurity lifecycle, where regulators expect a Software Bill of Materials (SBOM) and threat modeling.
- ISO 13485 provides the quality management system underpinning all of it.
In the US, the FDA regulates SaMD as a device. Since February 2, 2026, the Quality Management System Regulation (QMSR) has replaced 21 CFR Part 820 and incorporates ISO 13485:2016 by reference. For AI SaMD, the FDA reviews predetermined change control plans (PCCPs) so cleared models can update within pre-agreed limits.
AI-enabled SaMD carries an added layer in Europe: many Class IIa-and-above AI devices count as high-risk systems under the EU AI Act and must meet both the MDR and the AI Act.
Common challenges and best practices
The most common mistake is treating SaMD like consumer software. Agile and DevOps practices are fine, but they have to map onto IEC 62304 records: design inputs, traceability, verification evidence, and controlled releases. Teams that add documentation at the end usually pay for it in audit findings.
Intended-purpose drift is another trap. Marketing language that overstates what the software does can push it into a higher class or invite enforcement. Write the intended purpose precisely and hold the product to it.
Good practice runs safety, risk, and security as one workflow. IEC 62304, ISO 14971, and IEC 81001-5-1 were written to interlock, so a shared hazard analysis and a single traceability spine cut duplicated work. For AI models, plan post-market performance monitoring and define retraining boundaries before launch.
How SJML helps with Software as a Medical Device (SaMD)
SJML supports SaMD programs as part of its Compliance-as-a-Service offering. Its QARA teams work through the IEC 62304 software lifecycle, structure risk files to ISO 14971, and run IEC 81001-5-1 cybersecurity risk assessments for connected and standalone software. Support extends to device classification under EU MDR and FDA pathways, technical documentation, and EU AI Act readiness for AI-enabled products. Engineering and regulatory work sit under one roof, which helps teams align software architecture, quality records, and submission strategy from early design rather than reconstructing evidence later.
Frequently asked questions
SaMD is software that performs a medical purpose on its own, without being part of a hardware device, such as a diagnostic app or an image-analysis algorithm. Software in a Medical Device (SiMD) is embedded code that runs a physical device, like the firmware controlling an infusion pump. The EU groups both under Medical Device Software (MDSW).
Yes. The FDA regulates SaMD as a medical device based on its risk and intended use. Since February 2, 2026, SaMD manufacturers have followed the Quality Management System Regulation, which incorporates ISO 13485:2016. Depending on the class, the route may be a 510(k), De Novo, or premarket approval, and AI models can use predetermined change control plans.
Under Rule 11 of EU MDR Annex VIII, standalone software is classified from Class I to Class III based on how much its information influences clinical decisions and how serious the patient’s condition is. Guidance MDCG 2019-11 supports the assessment. Most SaMD falls into Class IIa or higher, and true Class I software is uncommon.
Core standards are IEC 62304 for the software lifecycle, ISO 14971 for risk management, IEC 62366-1 for usability, and IEC 81001-5-1 for cybersecurity, all sitting on an ISO 13485 quality system. AI-enabled SaMD in Europe also has to meet the EU AI Act, which applies from August 2026 with high-risk duties from August 2027.
Related terms
- Software in a Medical Device (SiMD)
- IEC 62304
- Medical Device Software (MDSW)
- Design Verification and Validation
- EU MDR Classification
