Software as a medical device (SaMD)
Also known as: SaMD, medical device software
Software as a medical device (SaMD) is software intended to diagnose, prevent, monitor, or treat a medical condition without being part of a physical medical device.
Examples include an app that detects atrial fibrillation from a smartwatch's data or an AI tool that flags strokes on brain scans. While a fitness app and a diagnostic app can look identical on your phone, regulators treat them very differently based on what the software claims to do.
Software as a medical device (SaMD), explained at three levels
At home
Think of the difference between a bathroom scale and a doctor's diagnosis. A step-counting app is like the scale: it reports numbers. Software becomes a medical device when it acts more like the diagnosis, claiming to detect, treat, or monitor a disease. SaMD is software that does that job on its own, on a phone, computer, or cloud server, without being part of a physical device, so regulators review it before it can be sold.
At work
SaMD is software whose intended purpose is medical, such as diagnosing a condition, guiding treatment, or monitoring a disease, and which runs independently of any hardware device. Regulators, including Health Canada and the FDA, treat it as a medical device. For a business, that classification decides whether a product needs clinical evidence, a quality management system, and a licence before sale, which shapes budgets, timelines, and marketing claims.
At home
Whether an app counts as a medical device depends on its intended use, meaning what the maker claims it does, not how the code works. A sleep tracker that shows hours slept is a wellness product. An app that claims to diagnose sleep apnea is a medical device. The same sensor data can sit behind both. That is why two similar-looking apps on your phone can face completely different rules, and why the regulated one must show evidence that its claim holds up.
At work
The IMDRF framework sorts SaMD by two factors: how serious the patient's condition is, from non-serious to critical, and how much the software's output matters, from informing management to driving it to diagnosing or treating directly. Higher combinations mean higher risk classes. Manufacturers then build a quality system to ISO 13485, follow IEC 62304 for software lifecycle processes, apply ISO 14971 risk management, add cybersecurity controls, and produce a clinical evaluation showing the software performs as claimed.
At home
Traditional device approval assumes a fixed product, but a machine learning model can change every time it is retrained on new data. That creates a gap: either freeze the model after approval or let it drift without review. Predetermined change control plans try to bridge it, with the maker describing in advance which updates it will make and how it will test them. While no plan can predict every change, in my opinion it is a sensible middle ground between freezing AI and letting it drift unchecked.
At work
SaMD risk sits in the whole lifecycle, not just the code. A model validated on one hospital's population can degrade on another's, so clinical validation across diverse groups and post-market performance monitoring matter. Changes need change control, either fresh review or an approved predetermined change control plan. Labelling must state intended use and limits. Cybersecurity follows standards such as IEC 81001-5-1. Clinical decision support exemptions differ between Health Canada, the FDA, and the EU MDR, so map each market separately.
Real-world examples
At home
Jerome's smartwatch alerted him to a possible irregular heart rhythm. His doctor explained that the watch's ECG feature was a regulated medical device function, unlike its sleep score, and ordered a follow-up test that confirmed atrial fibrillation.
At work
Aisha is the regulatory lead at a Montreal startup building an AI tool that reads skin photos. Because the tool suggests possible skin cancers, it counts as SaMD, so her team is collecting clinical evidence and preparing a Health Canada licence application.
Common confusions
- All health apps are medical devices. — Only software intended for medical purposes, such as diagnosis or treatment, is regulated as a device.
- Software inside a physical device is SaMD. — SaMD is standalone. Software that runs a physical device, like a pacemaker's firmware, is regulated as part of that device.
- Once approved, an AI device can be updated freely. — Significant changes usually need new review unless covered by an approved change control plan.
For analysts
Product teams should write the intended-use statement as early as the first prototype. I'd run every marketing claim past regulatory review, because a single sentence like 'detects disease' can turn a wellness app into a regulated device.
History & origin
Software inside devices, like pacemakers and infusion pumps, has been regulated for decades. As smartphones and cloud computing spread, regulators needed rules for standalone medical software. The International Medical Device Regulators Forum (IMDRF), which includes Health Canada and the US FDA, defined SaMD in 2013 and published a risk framework in 2014. The FDA cleared Apple Watch's ECG app in 2018, and the number of FDA-authorized AI-enabled devices grew past 1,000 by the mid-2020s, most in radiology. In late 2024, the FDA finalized guidance on 'predetermined change control plans' so AI devices could update under pre-agreed rules, and Health Canada followed with final guidance for machine learning-enabled medical devices in early 2025. In my view, SaMD regulation is where the 'move fast' culture of tech meets the 'first, do no harm' culture of medicine.