Updated: 20th June 2026
Reviewed by: David Small BSc (Hons), MSc, MTOPRA (Founder and CEO)
What is SaMD?
According to the International Medical Device Regulators Forum (IMDRF), SaMD is defined as software intended to perform one or more medical purposes without being part of a hardware medical device. Crucially, SaMD operates independently of any physical diagnostic or therapeutic hardware—it runs on general-purpose computing platforms, mobile devices, or in cloud environments.
Common examples of standalone medical software include:
Mobile apps that actively monitor or calculate insulin dosages for chronic diabetes management.
Computer-aided detection (CAD) software that analyzes medical images to identify malignant tumors.
Machine learning algorithms that process patient data streams to provide specific treatment recommendations to clinicians.
Key Architectural Note: If your software controls or directly drives a physical hardware medical device, it is typically classified as Software in a Medical Device (SiMD) or embedded firmware. If you are unsure which framework your product falls under, specialized SaMD consulting can help map your architecture before you commit to development.
New to Medical Device Software Development?
Software as a Medical Device (SaMD) is only one aspect of the medical device software lifecycle. For a complete guide to IEC 62304, including software safety classification, development planning, verification, validation and maintenance requirements, read our IEC 62304 Explained: Medical Device Software Development Guide.
Regulatory Considerations for SaMD
Navigating international regulatory frameworks remains one of the most significant hurdles for digital health startups and established manufacturers alike.
1. SaMD Under the EU MDR (2017/745)
Under the European Medical Device Regulation (MDR), the rules for software classification became substantially more stringent, particularly through the introduction of Rule 11. Most standalone software intended for diagnostic or therapeutic decision-making is automatically pushed out of Class I and into Class IIa, IIb, or Class III. This means that self-declaration is rarely an option; the vast majority of SaMD products entering the EU require a full Notified Body audit.
2. SaMD Under UK Regulations (MHRA)
In Great Britain, standalone software must comply with the Medical Devices Regulations 2002 and secure a UKCA mark. The MHRA places heavy emphasis on robust post-market monitoring and lifecycle risk management. Manufacturers must demonstrate strict adherence to ISO 14971 to identify and continuously mitigate software anomalies throughout the entire product lifecycle.
Technical and Development Challenges
Developing regulatory-compliant medical software requires balancing agile development speeds with rigid quality management guidelines:
Data Privacy and Cybersecurity: SaMD must adhere to strict data security frameworks, incorporating GDPR compliance by design alongside secure encryption protocols for transmitting patient health data.
Lifecycle Control (IEC 62304): Regulators require your software code to be built under a controlled lifecycle. For a comprehensive breakdown of software safety classes (Class A, B, C) and technical file documentation, see our complete guide on IEC 62304 compliance
How Specialized SaMD Consulting Drives Commercial Success
Errors made during the initial classification and design phases can lead to millions in lost development hours or catastrophic Notified Body rejections. Partnering with an experienced compliance team streamlines your route to market.
At Patient Guard, we provide end-to-end SaMD consulting to guide developers through complex digital health frameworks. Our services include:
Precise qualification and risk classification under EU MDR (Rule 11) and MHRA guidelines.
Establishing an ISO 13485 compliant Quality Management System (QMS) optimized for software lifecycles.
Compilation of audit-ready Technical Documentation, including software development plans, verification protocols, and traceability matrices.
Strategic alignment with evolving requirements, such as the EU AI Act and FDA digital health guidelines.
SaMD Regulatory & Compliance FAQ
Software qualifies as SaMD under the EU MDR if it has a specific medical intended purpose, such as diagnosing, preventing, monitoring, predicting, or treating a disease or injury. If the software merely logs data, manages administrative hospital tasks, or tracks general fitness, it does not qualify as a medical device.
SaMD can be updated as frequently as your development cycle requires, but you must implement a robust configuration and change management process under IEC 62304. Minor bug fixes or security patches rarely require regulatory re-submission, but any update that alters the core algorithm, changes the intended use, or impacts clinical safety requires a formal impact assessment and may require notifying your Notified Body or the MHRA.
Yes, AI and machine learning are increasingly common in SaMD, particularly for diagnostic imaging and triage. However, AI software faces intense regulatory scrutiny regarding algorithmic bias, transparency, and data training validation. Manufacturers must align their development with emerging frameworks like the EU AI Act and specific FDA/MHRA guiding principles for Good Machine Learning Practice (GMLP).
Cybersecurity is a core component of your technical file. Regulators expect manufacturers to implement secure lifecycle processes, perform continuous vulnerability testing, establish strict user access controls, and provide a software bill of materials (SBOM). You must demonstrate that your software is resilient against data breaches and unauthorized access that could compromise patient safety.
References
This guide is based on the following international standards, legislation and official regulatory guidance relating to Software as a Medical Device (SaMD), medical device software regulation and lifecycle compliance.
| Organisation | Reference | Why it's relevant |
|---|---|---|
| International Medical Device Regulators Forum (IMDRF) | Software as a Medical Device (SaMD): Key Definitions | Provides the internationally recognised definition of Software as a Medical Device (SaMD), which forms the foundation of regulatory approaches adopted by authorities worldwide. |
| European Union | Regulation (EU) 2017/745 on Medical Devices (MDR) | Establishes the European regulatory framework for medical devices, including standalone software and the classification requirements applied under Rule 11. |
| Medicines and Healthcare products Regulatory Agency (MHRA) | Software and Artificial Intelligence (AI) as a Medical Device | Provides UK regulatory guidance on Software as a Medical Device (SaMD), AI-enabled medical devices and software classification. |
| International Electrotechnical Commission (IEC) | IEC 62304 – Medical Device Software – Software Life Cycle Processes | Defines the internationally recognised software lifecycle processes expected during the development, maintenance and validation of medical device software. |
| International Organization for Standardization (ISO) | ISO 14971:2019 – Medical Devices – Application of Risk Management to Medical Devices | Provides the internationally recognised framework for identifying, evaluating and controlling risks associated with medical device software throughout its lifecycle. |
| U.S. Food and Drug Administration (FDA) | Software as a Medical Device (SaMD) | Explains the FDA's regulatory approach to standalone medical device software and its adoption of the IMDRF SaMD framework. |
Software regulation, international standards and regulatory guidance continue to evolve. Manufacturers should always consult the latest published legislation, standards and official guidance when developing, classifying and maintaining Software as a Medical Device throughout its lifecycle.
Patient Guards Recent Posts
Cosmetic Product Safety Report (CPSR): A Complete Guide to UK Cosmetic Compliance
Before a cosmetic product can legally be placed on the UK market, manufacturers and Responsible Persons must demonstrate that it is safe for human use under normal or reasonably foreseeable conditions. The Cosmetic Product Safety Report (CPSR) is one of the most important regulatory documents required under the UK Cosmetics Regulation. This guide explains what a CPSR is, who can prepare one, what information it must contain, how it relates to the Product Information File (PIF) and how it supports legal cosmetic compliance.
IVDR PMPF Explained: A Complete Guide to Post-Market Performance Follow-up
Post-Market Performance Follow-up (PMPF) is a fundamental requirement under the EU In Vitro Diagnostic Regulation (IVDR), ensuring that manufacturers continually monitor the scientific validity, analytical performance and clinical performance of their in vitro diagnostic medical devices after CE marking. This guide explains IVDR PMPF requirements, PMPF Plans, PMPF Reports, Annex XIII expectations and how ongoing performance monitoring supports continued regulatory compliance throughout the device lifecycle.
IVDR Scientific Validity Explained: A Complete Guide for Manufacturers
Scientific Validity is the first pillar of IVDR Performance Evaluation and provides the scientific foundation demonstrating that an analyte or biomarker is associated with a specific clinical condition or physiological state. This guide explains Scientific Validity under Regulation (EU) 2017/746, including literature reviews, Scientific Validity Reports, Annex XIII requirements, evidence appraisal and how Scientific Validity supports successful CE marking.
Patient Guards Related Services
Patient Guards Regulatory Tools
Need Training?
Do you need training on Quality Management Systems or EU MDR/ EU IVDR? then check out our training courses.
