Software as a Medical Device: FDA, EU MDR and UKCA routes for SaMD teams

Software teams meet the medical device regime later than hardware teams do, and usually at the worst moment: when a claim in the product copy turns a wellness app into a regulated device.

When software becomes a medical device

The trigger is intended purpose. Software intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease is a medical device in both the US and the EU. Software that only logs, displays or transfers data without interpreting it usually is not — until the interface starts recommending action.

Because the intended purpose is set by what you claim, the regulatory position of a product can change without a single line of code changing.

The US route

In the US, most SaMD reaching the market does so through 510(k) with a predicate under a software product code, or through De Novo where no predicate exists and risk is low to moderate. Clinical decision support that meets the statutory criteria may fall outside device regulation entirely, and certain low-risk software is covered by enforcement discretion. Expect questions on the software documentation level, cybersecurity, interoperability, and — for machine-learning models — the predetermined change control plan describing how the model may be updated after clearance.

The EU route

Under EU MDR, Rule 11 pushes most decision-influencing software into Class IIa or higher, which means a notified body is involved. Software driving decisions with serious deterioration or surgical intervention consequences moves to IIb, and those that may cause death or irreversible deterioration to III. Clinical evaluation expectations under MDR are substantially heavier than under the old directive, and notified body capacity remains a real timeline factor.

The UK route

Great Britain currently accepts UKCA marking, with CE-marked devices continuing to be accepted for a transitional period, while Northern Ireland follows EU rules. MHRA has set out a reform programme including specific provisions for software and AI as a medical device, so a launch plan should carry an assumption about which regime is in force at the intended launch date and be revisited.

Sequencing the three

The pragmatic order for most SaMD start-ups is: lock the intended purpose in writing, classify in each target market, then decide which market goes first based on evidence you already have rather than market size. The classification exercise usually surfaces claim wording that is worth changing before any submission work begins.

How DevicePath helps

DevicePath gives digital health and SaMD teams a fast triage: describe the software and its intended purpose and get the likely FDA class, candidate product codes, probable premarket pathway, 510(k) predicate candidates with K-numbers, and high-level EU MDR and UKCA / MHRA considerations. It is open source and free to try.