SaMD and the FDA framework

"They asked whether my model was accurate. The regulator asked what happens to a patient when it is wrong. I had spent a year answering the first question and five minutes on the second."

A Suddenly Humbled AI Agent

Intended use is the switch, not the technology

Software as a Medical Device (SaMD) is defined by the International Medical Device Regulators Forum (IMDRF) as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. The phrase that carries all the weight is intended for a medical purpose. A pulse-oximetry algorithm that says "your blood oxygen is 94 percent, consult a doctor if you feel unwell" and one that says "hypoxemia detected, adjust therapy" run identical arithmetic; the second makes a medical claim and the first tries not to. Regulators read your labeling, marketing, and user interface to infer intended use, so the claim is a decision you make, not an accident of the model.

This is why the FDA draws an explicit line around general wellness products. Software that promotes a general state of health or a healthy activity (a step counter, a relaxation-breathing coach, a sleep-quality score framed as lifestyle feedback) sits under enforcement discretion and is largely unregulated, provided it makes no claim to diagnose, cure, mitigate, or treat a disease. Cross that line, even with the same underlying PPG pipeline, and you are building a medical device. The engineering consequence is concrete: decide your intended-use statement before you freeze your dataset, because it determines which population you must sample, which endpoints you must measure, and what "good enough" means numerically.

The IMDRF risk grid: situation times significance

How much evidence a SaMD needs scales with its risk, and IMDRF defines risk along two axes that are worth memorizing. The first is the state of the healthcare situation: is the condition it addresses critical (life-threatening, time-sensitive), serious (moderate, curable but consequential), or non-serious? The second is the significance of the information the software provides to the clinical decision: does it treat or diagnose, does it drive clinical management, or does it merely inform management? Cross the two axes and you get four risk categories, I (lowest) through IV (highest). A tool that diagnoses a critical condition lands in category IV and will need the most evidence; one that informs management of a non-serious condition lands in category I.

This grid is not bureaucratic decoration. It is the same risk-based reasoning a safety engineer applies elsewhere in this book, the failure-mode-and-consequence thinking of Chapter 68, applied to clinical harm. It also tells you where to spend your uncertainty budget: a category IV output should almost never be a bare point estimate, which is exactly why calibrated confidence and abstention, the tools of Chapter 18, become mandatory rather than nice-to-have as you climb the grid. The short function below encodes the grid so you can classify a product idea in one call.

# IMDRF SaMD risk categorization: two axes -> category I (low) .. IV (high)
GRID = {
    # (situation,        significance)      : category
    ("critical",    "treat_or_diagnose"): "IV",
    ("critical",    "drive"):             "III",
    ("critical",    "inform"):            "II",
    ("serious",     "treat_or_diagnose"): "III",
    ("serious",     "drive"):             "II",
    ("serious",     "inform"):            "I",
    ("non_serious", "treat_or_diagnose"): "II",
    ("non_serious", "drive"):             "I",
    ("non_serious", "inform"):            "I",
}

def samd_category(situation, significance):
    key = (situation, significance)
    if key not in GRID:
        raise ValueError(f"unknown axes: {key}")
    return GRID[key]

# An AFib detector on a smartwatch: serious condition, drives a clinical visit.
print(samd_category("serious", "drive"))            # -> II
# A wrist tool claiming to diagnose a life-threatening arrhythmia:
print(samd_category("critical", "treat_or_diagnose"))  # -> IV

As Listing 34.1 makes vivid, the same organ and the same sensor can produce a category II or a category IV device depending only on the claim in the second axis. That is the intended-use switch of the previous section, now quantified.

Pathways to market: 510(k), De Novo, and PMA

The FDA sorts devices into three regulatory classes by risk. Class I (low risk, most general wellness-adjacent tools) faces general controls only. Class II (moderate risk, where most wearable clinical software lands) usually reaches market through a 510(k) submission, in which you demonstrate substantial equivalence to a legally marketed predicate device. Class III (highest risk, sustaining or supporting life) requires premarket approval (PMA), the most demanding pathway, typically backed by a prospective clinical trial of the kind designed in Section 34.3. A fourth door, De Novo classification, exists for genuinely novel low-to-moderate-risk devices that have no predicate: it lets a first-of-a-kind product establish itself as a new Class I or II device and become a predicate for others. Several early AI-based ECG and retinal-screening products walked through the De Novo door precisely because nothing like them existed to be equivalent to.

Substantial equivalence is where many machine-learning teams stumble. It does not mean "as accurate as"; it means same intended use and same technological characteristics, or different characteristics that do not raise new questions of safety and effectiveness. A model that swaps a hand-engineered feature set for a deep network may be more accurate yet still trigger new questions (about training-data representativeness, about failure modes) that a predicate never had to answer. The regulatory work is not proving you are better; it is proving you are not newly dangerous.

Where AI stresses the framework, and how the FDA responds

The classical framework assumes a device is locked: it behaves the same after clearance as during evaluation. A learning model that keeps adapting to new data breaks that assumption, because the artifact you validated is not the artifact in the field. The FDA's response has three pillars worth naming. First, Good Machine Learning Practice (GMLP), a set of guiding principles co-authored with Health Canada and the UK MHRA, covering representative data, leakage-safe train-test separation, human-factors design, and monitored deployment; much of it is the discipline this book has taught, now made an expectation. Second, the requirement to establish clinical evidence along three legs (IMDRF again): a valid clinical association between your output and the clinical condition, analytical validation that your software correctly processes the input, and clinical validation that the output achieves the intended purpose in the target population. Third, and specific to adaptive models, the predetermined change control plan (PCCP), a pre-authorized envelope of allowed model updates, which earns its own Section 34.2 because it is how a learning system stays compliant while still learning.

import requests

url = "https://api.fda.gov/device/510k.json"
params = {"search": 'device_name:"atrial fibrillation"', "limit": 5}
hits = requests.get(url, params=params, timeout=30).json()["results"]

for h in hits:
    print(h["k_number"], h["decision_date"], h["device_name"])

What's Next

In Section 34.2, we open the predetermined change control plan in detail: how a team pre-specifies the space of allowed model updates, the retraining triggers, and the performance guardrails so a learning SaMD can improve in the field without returning to the regulator for every new weight, turning the locked-device assumption from a hard wall into a governed envelope.