Medical AI · Regulation, ethics & governance · Lesson 1 of 7

Software as a Medical Device (SaMD)

Reviewed by Dr. Ram Kumar G, MBBS, MD (Internal Medicine), MPH (USA), on 2026-10-18 · Last updated 2026-10-18

Beginner
Clinical focus
About 25 minutes
Includes exercise

Before this lesson: The healthcare-AI landscape: what is in use, what works, and what to ask

In short

Software as a Medical Device (SaMD) is software intended for a medical purpose, such as diagnosing, monitoring or guiding treatment, that achieves that purpose without being part of a hardware device. Whether software is a medical device depends on its intended purpose, as stated by the manufacturer, not on whether it uses AI. Risk depends on how serious the condition is and how much the software's output drives clinical decisions, and higher risk means more evidence and oversight.

You will learn to

Define Software as a Medical Device and explain why intended purpose decides it
Distinguish SaMD from software in a device and from software that is not a device
Use the IMDRF framework to categorise SaMD risk
Describe what regulators expect across the software life cycle

What makes software a medical device

The International Medical Device Regulators Forum (IMDRF), whose members include regulators from the US, EU, UK, India, Japan and others, defines SaMD as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. National laws have their own wording, but the central idea is shared: the intended purpose decides.

Illustrative. Classification depends on the exact intended purpose and the law of each jurisdiction.
Software	Usually a medical device?	Why
AI that reads retinal photos to detect diabetic retinopathy	Yes (SaMD)	Medical purpose: diagnosis
Insulin dose calculator	Yes (SaMD)	Medical purpose: guiding treatment
Software that runs inside an insulin pump	Yes, as part of the device	Software in a medical device, regulated with the pump
Appointment booking or billing software	No	No medical purpose
A general fitness tracker for wellbeing	Usually no	General wellness, not diagnosis or treatment
A general-purpose chatbot	Depends	Not a device in itself; a product built on it and intended for medical use can be

Intended purpose: the deciding factor

Intended purpose comes from the manufacturer's labelling, instructions, marketing and claims. The same algorithm can be a device in one product and not in another.
Claims matter: 'helps you track your sugar readings' and 'tells you how much insulin to take' describe very different regulatory products.
Building on a general AI model does not avoid regulation. If a product is intended for a medical purpose, it is assessed as a medical device whatever is inside it.
Organisations that build AI tools for their own clinical use should check whether in-house or health-institution exemptions apply where they work; these differ between countries.

Categorising risk

The IMDRF risk framework (2014) combines two questions: how serious is the healthcare situation, and how significant is the software's information to the decision? Categories run from I (lowest) to IV (highest). In January 2025 the IMDRF published updated considerations for characterising medical device software and its risks (N81), which build on this approach. Regulators use their own class systems, but the logic is similar.

python

# IMDRF SaMD risk categories (N12, 2014): state of the healthcare situation x significance of the information
CATEGORY = {
    ("critical", "treat or diagnose"): "IV", ("critical", "drive clinical management"): "III",
    ("critical", "inform clinical management"): "II",
    ("serious", "treat or diagnose"): "III", ("serious", "drive clinical management"): "II",
    ("serious", "inform clinical management"): "I",
    ("non-serious", "treat or diagnose"): "II", ("non-serious", "drive clinical management"): "I",
    ("non-serious", "inform clinical management"): "I",
}

examples = [
    ("Autonomous diabetic retinopathy screening result", "serious", "treat or diagnose"),
    ("Insulin dose calculator for type 1 diabetes", "critical", "drive clinical management"),
    ("Sepsis early-warning score shown to ward staff", "critical", "inform clinical management"),
    ("App summarising home glucose readings for the clinician", "non-serious", "inform clinical management"),
]
for name, situation, significance in examples:
    print(f"Category {CATEGORY[(situation, significance)]:<3} {name}  ({situation}; {significance})")

# Category III Autonomous diabetic retinopathy screening result  (serious; treat or diagnose)
# Category III Insulin dose calculator for type 1 diabetes  (critical; drive clinical management)
# Category II  Sepsis early-warning score shown to ward staff  (critical; inform clinical management)
# Category I   App summarising home glucose readings for the clinician  (non-serious; inform clinical management)

The IMDRF SaMD risk categories, applied to four illustrative diabetes-related tools.

The situation and significance assigned to each example are teaching assumptions. A manufacturer's actual intended purpose, and a regulator's view, decide the real category.
Moving from 'inform' to 'drive' or 'diagnose' raises the category. That is why claims of autonomy, such as 'no specialist needed', bring more scrutiny.

What regulators expect across the life cycle

Regulators assess software over its whole life, not just at approval. The IMDRF's Good Machine Learning Practice principles (final version January 2025), aligned with earlier principles from the US FDA, Health Canada and the UK MHRA, set out shared expectations.

Stage	Typical expectations
Design	A clear intended purpose and users; a risk-management process; a quality-management system
Data and development	Representative, well-managed data; training and test sets kept independent; clinically relevant performance targets
Validation	Clinical evidence proportionate to risk; performance in the intended population and relevant subgroups
Transparency	Clear information for users on intended use, performance and limitations
After release	Post-market surveillance, monitoring for drift, controlled updates, incident reporting

Not legal or regulatory advice

This lesson explains regulation for learning purposes, as of October 2026. Rules and guidance change; whether a real product is a medical device, and how it is classified, depends on its intended purpose and needs qualified regulatory advice and the current official texts.

Exercise

Practise deciding whether software is a medical device and categorising its risk.

Data: Ten fictional product descriptions written for the notebook (Created for this course)

For each fictional product, write its intended purpose in one sentence using the product's own claims.
Decide whether it is likely to be SaMD, software in a device, or not a device, and explain why.
Assign an IMDRF category with the code above, stating your assumptions about the situation and significance.
Rewrite the claims of one product so that it would no longer be a medical device, and discuss whether that would still be useful clinically.

The runnable notebook and worked solution will be published soon. You can work through the steps with the code on this page in the meantime.

Key takeaways

Software is a medical device when its intended purpose is medical, whether or not it uses AI.
Claims and labelling define intended purpose; the same algorithm can be regulated differently.
Risk rises with the seriousness of the condition and how much the output drives decisions.
Regulators expect quality management, evidence and monitoring across the whole life cycle.

Terms used: Intended purpose (intended use), SaMD (Software as a Medical Device)

FAQ

What is Software as a Medical Device?

Software intended for a medical purpose, such as diagnosis, monitoring or treatment, that performs that purpose without being part of a hardware medical device.

Is all clinical AI a medical device?

No. Software with no medical purpose, such as scheduling or billing, is not. Whether clinical software is a device depends on its intended purpose and the law in each country.

Does using a general-purpose AI model avoid medical device rules?

No. If a product built on such a model is intended for a medical purpose, it is assessed as a medical device.

What is the IMDRF?

The International Medical Device Regulators Forum, a group of national regulators that develops shared approaches to medical device regulation, including for software and AI.

Are hospital-built AI tools regulated?

It depends on the country. Some laws have exemptions for devices made and used within a health institution, with conditions. Check local rules before deploying in-house tools.

Sources

Educational content only. This material teaches methods; it is not clinical advice. Code, models and examples here are not validated medical devices and must not be used to make decisions about real patients without proper clinical validation, governance and any required regulatory approval. Examples use synthetic or openly licensed de-identified data only. Never paste identifiable patient information into public AI tools. Mentions of models, tools or vendors are for identification, not endorsement.