Software as a Medical Device (SaMD)

What is SaMD software as a medical device?

Software as a Medical Device (SaMD) refers to software intended to be used for one or more medical purposes without being part of a hardware medical device. SaMD can function on general-purpose computing platforms or mobile devices and is used to diagnose, treat, or prevent diseases or other conditions. Unlike software embedded within medical hardware, SaMD operates independently to provide critical information for healthcare decisions. Regulatory bodies, such as the FDA and EMA, evaluate SaMD based on its intended use and its potential risks, ensuring it meets stringent safety and effectiveness criteria before market release.

Difference between SaMD and non-SaMD

The distinction between Software as a Medical Device (SaMD) and non-SaMD revolves primarily around the intended medical use and regulatory oversight:

• Intended Use:

• SaMD: This software is specifically intended for one or more medical functions, such as diagnosing, monitoring, or treating a medical condition. SaMD can perform these functions without being part of any physical medical device. It operates independently and delivers medical outcomes through algorithms and data processing capabilities. Examples include apps that monitor blood glucose levels or software that analyzes medical images to detect abnormalities.
• Non-SaMD: This software includes applications that may be used in a healthcare setting but do not have a direct medical purpose. Non-SaMD typically supports healthcare systems, such as electronic health records (EHRs), hospital management systems, or software that operates integrated medical device hardware (like firmware). These are often termed Software in a Medical Device (SiMD) or general health and wellness apps.

• Regulatory Oversight:

• SaMD: Due to its direct impact on patient care, SaMD is heavily regulated by authorities such as the FDA in the U.S. or the EMA in Europe. Before being marketed, these products must meet stringent regulatory requirements concerning safety, effectiveness, and quality.
• Non-SaMD: While some non-SaMD may still require compliance with certain privacy and security regulations (like HIPAA in the U.S. for patient data protection), they typically do not undergo the rigorous pre-market approval processes required for SaMD unless they directly interface with medical device functions.

The key difference hinges on whether the software is designed to carry out medical functions independently (SaMD) or support medical or administrative processes without directly contributing to diagnosing, treating, or managing a disease or condition (non-SaMD).

What is an example of a SaMD?

Examples of Non-SaMD Software

• Electronic Health Records (EHRs)
• Hospital scheduling software
• Patient registration systems
• Medical billing software
• Video consultation platforms used only for communication

Software as a Medical Device spans a wide range of clinical use cases today, from AI-assisted diagnosis to chronic disease management. Here are real-world examples across major categories:

AI Diagnostics AI-powered diagnostic software analyzes medical images or clinical data to detect conditions earlier and more consistently than manual review alone. Examples include Viz.ai, which uses AI to detect signs of stroke in CT scans and alert care teams faster, and Digital Diagnostics' EyeArt, an autonomous AI system that screens for diabetic retinopathy directly from retinal images.

Cardiac Monitoring Cardiac SaMD tools let patients and clinicians monitor heart activity outside a hospital setting, often continuously and remotely. AliveCor's KardiaMobile analyzes ECG readings to detect atrial fibrillation and other arrhythmias, while Eko Health's software analyzes heart and lung sounds captured through a digital stethoscope to flag potential abnormalities.

Diabetes Management Continuous glucose monitoring software helps patients and providers manage diabetes with real-time data rather than periodic manual testing. Dexcom's CGM apps process sensor data to deliver real-time glucose readings, trend alerts, and insights that support day-to-day diabetes management decisions.

Medical Imaging AI-driven imaging software helps radiologists prioritize and analyze scans faster, particularly for time-sensitive conditions. Aidoc, Arterys, and Subtle Medical all provide AI analysis of CT, MRI, and PET scans, helping flag urgent findings, quantify imaging data, or enhance image quality for faster, more confident interpretation.

Digital Therapeutics Digital therapeutics deliver clinically validated treatment through software, often as an adjunct to medication rather than a replacement for it. Click Therapeutics has received FDA marketing authorization for multiple prescription digital therapeutics, including CT-132 for the preventive treatment of episodic migraine and Rejoyn (developed with Otsuka) for major depressive disorder, both delivered through smartphone-based programs used alongside standard treatment.

Examples of Non-SaMD Software

Not all software used in healthcare qualifies as SaMD - software that supports clinical or administrative operations without performing a medical function on its own falls outside the definition:

• Electronic Health Records (EHRs) - store and organize patient data but don't diagnose, treat, or monitor a condition themselves.
• Hospital scheduling software - manages appointments, staff, and resources without any direct clinical function.
• Patient registration systems - capture administrative and demographic information for care coordination, not diagnosis or treatment.
• Medical billing software - processes claims and payments, entirely separate from clinical decision-making.
• Video consultation platforms used only for communication - facilitate a conversation between patient and provider but don't themselves analyze data or inform a medical decision.

What are the categories of SaMD?

Software as a Medical Device (SaMD) can be categorized based on the level of risk associated with their intended medical use. The International Medical Device Regulators Forum (IMDRF) outlines a framework to classify SaMD based on the significance of the information provided by the software to healthcare decisions and the state of the healthcare situation or condition. Here are the categories:

• Category I (Low Risk):

• SaMD is intended to provide information to inform clinical management for non-serious conditions. This category includes software that may help manage conditions but does not direct or drive clinical management and has minimal impact if it fails.

• Category II:

• SaMD is intended to inform clinical management of serious conditions. This category includes software that is important in informing healthcare professionals’ decisions regarding serious conditions but does not directly guide immediate or critical actions.

• Category III:

• SaMD is intended to drive the clinical management of serious conditions. This software provides crucial information used to take immediate or critical actions; the accuracy and reliability of such software are paramount because any malfunction could have severe consequences.

• Category IV (High Risk):

• SaMD is intended to treat or diagnose, guide treatment, drive clinical management, or perform triage in critical conditions. The software in this category can directly impact patient care by suggesting or informing interventions and treatments. Malfunctions or inaccuracies in these applications could result in significant or immediate life-threatening situations.

Each category requires a different level of regulatory scrutiny, with higher-risk categories (III and IV) undergoing more rigorous evaluation processes to ensure safety and efficacy before and after entering the market. This classification helps regulatory bodies and manufacturers manage and mitigate risks associated with SaMD products effectively.

Regulatory Guidelines for Software as a Medical Device (SaMD)

The FDA regulates Software as a Medical Device using a risk-based approach, meaning the level of regulatory scrutiny a SaMD product faces depends on its intended use and its potential impact on patient safety - not on the fact that it's software. A low-risk wellness app faces a very different regulatory path than software intended to drive treatment decisions in a critical condition.

Across SaMD products, FDA guidance generally expects manufacturers to address:

• Software verification and validation - demonstrating that the software performs as intended and reliably produces accurate outputs across its intended use conditions.
• Quality management system requirements - maintaining a QMS (aligned with the FDA's QMSR and ISO 13485:2016) that governs how the software is designed, developed, tested, and maintained.
• Risk assessment and risk controls - identifying potential failure modes and their clinical consequences, and implementing controls to mitigate them, consistent with ISO 14971 risk management principles.
• Cybersecurity and data protection - securing the software against vulnerabilities that could compromise patient data or device function, an area of increasing FDA scrutiny for any connected or AI-enabled software.
• Clinical or performance evidence - providing data demonstrating the software's clinical validity and, where applicable, clinical benefit, appropriate to its risk category.
• Post-market monitoring - tracking real-world performance after release, including adverse event reporting and monitoring for software updates that could affect safety or effectiveness.
• Documentation and traceability - maintaining complete, traceable records connecting design inputs, testing, risk controls, and validation evidence, so the software's safety case can be reconstructed and defended during a regulatory review.

These guidelines exist to ensure that as software takes on a more direct role in diagnosis and treatment, it's held to the same rigor as any other medical device - supporting not just regulatory compliance, but the underlying software quality and patient safety that compliance is meant to protect.

Frequently Asked Questions (FAQs)