Updated 20th June 2026
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.
Patient Guards Recent Posts
EU Authorised Representative Services for Medical Device & IVD Manufacturers
Selling medical devices or IVDs in Europe? If your company is based outside the EU, appointing an EU Authorised Representative (EC Rep) is a legal requirement under EU MDR 2017/745 and IVDR 2017/746. Patient Guard provides expert EU Authorised Representative services, EUDAMED support, regulatory guidance, and ongoing compliance management to help manufacturers access and maintain the European market with confidence.
Predetermined Change Control Plans (PCCPs): The Future of Agile Compliance for Medical Device Software
Learn how PCCPs help medical device software manufacturers manage updates, support AI systems, and enable agile compliance under evolving MDR and UKCA frameworks.
The AI Act Omnibus Explained: What the 2026 EU Rules Mean for Medical Device and IVD Manufacturers
Discover how the EU AI Act Omnibus affects AI medical devices and IVD manufacturers. Learn about the No Duplication principle, transparency rules, key 2026 and 2028 deadlines, and how MDR and IVDR compliance are converging with AI regulation.
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.
