SaMD Classification 101: How to Determine If Your Algorithm Is a Medical Device Before the Regulator Does

The most expensive regulatory mistake a health AI startup can make is discovering late that their algorithm is a medical device.

Not because being a medical device is catastrophic. It isn't. Plenty of profitable, well-funded health AI companies operate as regulated medical device manufacturers. The problem is discovering it late: after you've built an architecture, collected data, signed clinical partnerships, and sometimes shipped to users without the design controls, documentation, and validation infrastructure medical device software requires. Retrofitting these onto an existing product is significantly harder and more expensive than building them in from the start. We've seen retrofits eat 12+ months and several million euros of additional spend on programs that would have been routine if classification had been settled in month one.

This article is about how to make that determination early, before your first clinical partnership, before your Series A, and ideally before you write much code. The frameworks exist. The analysis is tractable. What's missing for most founders is a clear explanation of how to apply them.

This is a companion piece to our articles on building cardiac AI to clinical-grade — the engineering view and the business view. Once you've determined you're a medical device, those articles describe what comes next.

Why "medical device" applies to more software than you think

Founders often assume "medical device" means physical hardware such as an ECG monitor, an infusion pump, a surgical robot. Software that merely processes health data, displays information, or supports clinical workflows sits in a grey zone, they assume.

This assumption is wrong in the EU, the US, the UK, and most other major regulatory jurisdictions.

All major Western regulators have explicit frameworks for Software as a Medical Device (SaMD) — software that performs one or more medical purposes independently of a hardware medical device. The International Medical Device Regulators Forum (IMDRF), whose SaMD definition underpins regulators in the US, EU, UK, Canada, Australia, Singapore, and Japan, defines SaMD as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."

If your algorithm is intended to diagnose a condition, predict a patient outcome, recommend a treatment, monitor a patient's condition, or detect a disease, it is almost certainly a medical device, regardless of whether it runs on a phone, a web server, or a hospital workstation.

Architectural choices don't change this. Disclaimers don't change this. The fact that "a clinician makes the final decision" doesn't change this. Classification is determined by the intended purpose of your software, not by how you frame it.

The IMDRF SaMD framework: the first filter

The IMDRF SaMD classification framework (IMDRF/SaMD WG/N12FINAL) classifies software on two dimensions:

Significance of information provided to the healthcare decision: treat or diagnose, drive clinical management, or inform clinical management.

State of the healthcare situation: critical (life-threatening or time-critical), serious, or non-serious.

The matrix produces four SaMD categories:

Category IV is highest risk; Category I is lowest. The framework matters because it's the reference both FDA and EU regulators use when assessing what controls are appropriate, and because it predicts where your device will land before you file anything.

A few worked examples threaded through the regulatory regimes that follow:

An algorithm that interprets a 12-lead ECG in an emergency department, flagging suspected STEMI for immediate cath lab activation: Treat/Diagnose × Critical = Category IV. Likely EU MDR Class IIb (decisions could lead to serious deterioration if missed); FDA 510(k) or De Novo depending on predicate availability.

An algorithm that analyses retinal images to detect diabetic retinopathy and flags them for ophthalmologist review: Treat/Diagnose × Serious = Category III. Typically EU MDR Class IIa; FDA De Novo path (the route IDx-DR took).

A wearable AFib detection feature that alerts the user to consult a healthcare professional if irregular rhythm is detected: Inform × Serious = Category I under IMDRF, despite which it is still typically EU MDR Class IIa and FDA Class II under De Novo (the path Apple Watch's AFib feature took). The IMDRF framework is a risk taxonomy; MDR and FDA classes are regulatory paths. They overlap but don't equate.

A 30-day hospital readmission risk score surfaced on a clinical dashboard: Inform × Serious = Category I under IMDRF, but likely EU MDR Class IIa under Rule 11.

An algorithm that suggests dietary recommendations in a non-clinical wellness app: Inform × Non-serious = Category I under IMDRF, and outside medical device regulation entirely under FDA's General Wellness policy if no specific disease claims are made.

The takeaway: IMDRF is your first filter for thinking about risk, but it doesn't determine your regulatory path. The jurisdiction-specific rules below do.

EU MDR: the Rule 11 analysis

Under EU MDR, software classification is governed primarily by Rule 11 in Annex VIII. The actual rule structure for software providing information used in clinical decisions:

Class IIa (default): Software providing information used to take decisions with diagnostic or therapeutic purposes. Most AI diagnostic decision-support software lands here.

Class IIb: Where decisions could cause serious deterioration of a person's state of health or a surgical intervention.

Class III: Where decisions could cause death or irreversible deterioration of a person's state of health.

A separate sub-rule covers monitoring software:

Class IIa (default for monitoring): Software intended to monitor physiological processes.

Class IIb (monitoring): Software for monitoring vital physiological parameters where variation could result in immediate danger.

Software not falling into any of these categories is Class I. Under Rule 11, Class I is rare in practice for health AI; most genuinely diagnostic or therapeutic-decision-supporting software lands in IIa or IIb.

Worked applications:

An AI system that flags potential cardiac abnormalities for cardiologist review: Class IIa. Decisions are reviewed by a clinician; the consequence of an error is serious but not directly causing death or irreversible deterioration in the clinician-in-the-loop pathway.

An AI system that predicts sepsis risk and surfaces it on a clinical dashboard: typically Class IIb. The information drives decisions whose consequence (missed sepsis) could be serious deterioration or death.

An AI system that automatically adjusts insulin delivery based on glucose monitoring: Class III under broader MDR rules, because it directly drives a treatment with immediately dangerous consequences.

The "potential consequence" analysis is where most classification disputes arise. Consequence depends on clinical context, urgency, and whether a clinician reviews the output before action. Documenting your intended use precisely — specifying that outputs are reviewed by qualified clinicians, specifying clinical context — can shift the consequence analysis and thus the classification.

For genuinely borderline products, three formal mechanisms exist: the MDCG (Medical Device Coordination Group) borderline guidance documents, a written classification opinion from a notified body, or pre-submission interaction with a competent authority. These are formal regulatory channels, not informal consulting, and are significantly cheaper than discovering mid-project that your classification was wrong.

EU AI Act: the overlay that adds a second regulatory regime

For health AI products in the EU, the AI Act now sits on top of MDR. As of May 2026, with high-risk AI Act provisions phasing in from August 2026, this is the single biggest active source of founder confusion in health AI regulation.

The structure: medical device software regulated as Class IIa, IIb, or III under MDR is automatically classified as high-risk under the AI Act (Article 6, in conjunction with Annex I covering devices that require third-party conformity assessment). There is no design choice that avoids high-risk classification for regulated medical device AI.

What high-risk classification adds, on top of MDR:

Documented training data governance — data quality, representativeness, bias testing, demonstrating the data was appropriate for the intended use.

Transparency provisions to deployers (hospitals, clinics) about capabilities, limitations, expected accuracy, and intended use sufficient for safe operation.

Human oversight mechanisms documented in the design — for clinician-in-the-loop SaMD this is straightforward; for autonomous decision systems it's a meaningful design constraint.

Post-market monitoring of the AI system specifically, overlapping with but distinct from MDR post-market surveillance.

Conformity assessment of the AI system. For SaMD that already requires notified body involvement under MDR, the AI Act conformity assessment is largely integrated into the existing path; the documentation burden is real but the procedural route exists.

The strategic implication: any health AI program targeting EU launch in 2026 or later needs to plan AI Act compliance as a parallel workstream from day one, not retrofit it after MDR. Programs already through MDR conformity assessment have a meaningful head start over new entrants who must clear both regimes simultaneously.

FDA: software function regulation and the CDS carve-out

FDA's approach to SaMD classification maps roughly onto IMDRF but is operationally distinct. FDA uses guidance on device software functions to determine which functions are regulated as devices and which fall outside oversight.

Software FDA does not regulate as a medical device: administrative software (scheduling, billing, communication); general wellness software not making specific health recommendations; electronic patient records not intended for clinical decision support; software that transfers, stores, or displays clinical lab results without interpreting them.

Software FDA does regulate: software that analyses patient-specific data to make or aid in a diagnostic or treatment recommendation; software providing patient-specific alerts based on clinical data; software performing image analysis for diagnostic purposes; software analysing physiological signals for clinical purposes.

The Clinical Decision Support (CDS) carve-out — codified in the 21st Century Cures Act, implemented through FDA's final CDS guidance (September 2022) — is the part of FDA's framework founders most often misread. The four criteria, all four of which must be satisfied, are:

1. The software does not acquire, process, or analyse a medical image, a signal from an in vitro diagnostic device, or a pattern/signal from a signal acquisition system.
2. The software displays, analyses, or prints medical information about a patient or patient population.
3. The software provides recommendations to a healthcare professional, not directly to a patient.
4. The software provides the basis for the recommendation in a way that allows the healthcare professional to independently review it and not rely primarily on it.

Criterion (1) is where most AI medical software fails the carve-out, regardless of how transparent the model is. If you analyse ECG signals, retinal images, dermatology photos, pathology slides, ultrasound, MRI, or any signal from a medical signal-acquisition system, you are not eligible for the non-device CDS exemption. Period. Transparency, explainability, and clinician-in-the-loop don't matter for criterion (1); the input modality alone disqualifies you.

The transparency criterion (criterion 4) is the one founders fixate on, and it does matter — but only for non-image, non-signal CDS. Natural language processing of clinical notes, risk scoring on structured EHR data, alert systems built on lab values you didn't acquire yourself: for these, an explainable model that surfaces its reasoning is meaningfully easier to keep outside FDA regulation than a black-box one. For image and signal AI, focus your energy elsewhere.

For founders building image or signal AI, the realistic FDA pathway is 510(k) clearance if a substantially equivalent predicate device exists, or De Novo classification if it doesn't. Both are device pathways, not exemptions.

IVDR: the other path you may be on without knowing it

Some software is regulated under EU In Vitro Diagnostic Regulation (IVDR, 2017/746), not MDR. This catches founders by surprise.

IVDR applies to software that interprets the output of an in vitro diagnostic test — lab results, genomic sequencing data, biomarker measurements, microbiome analysis, immunoassay outputs. If your software's primary function is to interpret data from a sample taken from the human body and processed in vitro, you are likely an IVDR product.

IVDR has its own classification system (Classes A, B, C, D) under different rules from MDR Rule 11. Class C and D devices face notified body involvement. Class B devices face notified body conformity assessment for some aspects. Class A is lowest risk. Many AI products interpreting genomic or biomarker data land in Class C, which carries substantial conformity assessment burden.

Founders building genomics AI, biomarker AI, microbiome AI, or lab-result-interpretation AI should classify under IVDR, not MDR. The technical and clinical evaluation requirements have substantial overlap, but the rules and conformity routes are different.

US founders building IVD software face FDA regulation under 21 CFR 809 plus the relevant device classification (clinical chemistry, immunology, hematology), with overlapping SaMD principles. AI-driven IVD products are increasingly going through De Novo or 510(k).

UKCA, MHRA, and the continuing UK transition

For UK-based startups, the Medicines and Healthcare products Regulatory Agency (MHRA) has been operating a phased transition away from retained EU MDR/IVDR rules. The position has shifted multiple times since Brexit, and any specific date in any explainer (including this one) should be checked against MHRA's currently published roadmap before being relied on.

The current shape: CE-marked devices continue to be accepted in Great Britain for defined periods, with phase-out timelines varying by device class. The new UK regulations are being implemented in phases through 2025–2027, with post-market surveillance regulations and core regulations rolling in at different points.

The practical implication for founders: build the underlying technical documentation — clinical evaluation, ISO 13485 QMS, IEC 62304 software documentation, ISO 14971 risk management, IEC 62366-1 usability — to a standard that satisfies both EU MDR and UK MDR. The substance is largely aligned. The conformity assessment routes (EU Notified Bodies vs. UK Approved Bodies) are separate, but the underlying file is the same. For startups with NHS commercial ambitions, UK conformity is a prerequisite; for EU commercial ambitions, CE mark is the route; for both, the documentation work is parallel rather than duplicative.

MHRA also runs the AI Airlock programme — a regulatory sandbox specifically for AI medical devices, useful for early-stage products navigating ambiguous classification or novel intended uses. The EU AI Act mandates AI regulatory sandboxes at member-state level. For genuinely early-stage health AI in grey zones, sandboxes are an underused option.

The grey zone: where founders get it wrong

Three categories of software are consistently misclassified by founders.

"It's just showing the doctor information, not making a decision." Both EU MDR and FDA frameworks regulate software that provides information used in clinical decision-making — not just software that makes automated decisions. If your algorithm analyses patient data and outputs a risk score, a probability, a flag, or a ranked list that a clinician then uses to make a clinical decision, you are providing information used in decision-making. You are likely a medical device.

"It's a wellness app, not a clinical tool." The regulatory boundary between wellness and clinical is determined by the claimed and reasonably foreseeable use of the software, not by what the developer calls it. If your "wellness" algorithm analyses physiological data to flag a potentially serious condition — even informally, even with disclaimers — regulators look at the actual function, not the label.

Disclaimers that say "this is not medical advice" do not change the regulatory status of software that performs medical device functions. This is the single most expensive misconception in early-stage health AI.

FDA's General Wellness policy provides a narrow safe harbour for software that maintains or encourages general health (sleep tracking, fitness encouragement, stress management) without making specific disease claims. The moment your "wellness" product makes any specific disease detection or risk claim, the safe harbour evaporates.

"We're only for research use only (RUO) or investigational use." RUO is a specific FDA labelling exemption for in vitro diagnostic products in pre-market research, not a general protection for SaMD. For software more broadly, the relevant pre-market routes are FDA's Investigational Device Exemption (IDE) for clinical investigations, or the EU's clinical investigation provisions under MDR.

In all cases, the protection is conditional on actual research use. If an RUO-labelled or investigational-labelled tool is being used in clinical practice — even informally, even without explicit promotion — the protection evaporates. FDA has taken enforcement action against companies whose RUO-labelled software was used clinically. NHS partnerships and hospital pilots that drift toward routine clinical use are a particularly common way to lose investigational protection without realising it.

Cost and timeline implications by class

A rough sense of what each classification costs in time and money for a typical health AI startup, drawn from programs we've worked with:

FDA non-device CDS or General Wellness: No FDA submission required. Time-to-market: weeks to months. Regulatory cost: low — legal opinion, documented intended-use analysis. The catch: the criteria are narrow and image/signal AI doesn't qualify.

EU MDR Class I: Self-declaration of conformity, no notified body involvement for most Class I. Total regulatory effort: 6–12 months and €50K–200K. Increasingly rare for health AI under Rule 11.

EU MDR Class IIa (most diagnostic decision support AI): Notified body involvement. Total regulatory effort from a serious start: 12–24 months and €300K–800K, plus 5–10 person-years of regulatory writing and clinical evaluation. Notified body fees alone often €100K–300K.

EU MDR Class IIb / III (high-risk decision support, autonomous treatment): 24–48 months and €1M–5M+ depending on clinical evaluation scope and whether new clinical investigations are required.

FDA 510(k) (predicate-based clearance): 9–18 months from submission, plus 6–18 months of preparation. €300K–1M+ depending on clinical data needs. Available only if a substantially equivalent predicate device exists.

FDA De Novo (no predicate): 12–24 months from submission, plus extensive preparation. €1M–3M+. The first-of-its-kind cardiac AI products typically went through De Novo.

A binding constraint many founders miss: notified body capacity in Europe is currently a real bottleneck. Engaging a notified body and getting on their schedule should be done before you need them, not after. Some categories of devices have current waits of 12+ months just to start the conformity assessment process.

These numbers are why classification matters. The difference between Class I and Class IIa is roughly a year and several hundred thousand euros. The difference between Class IIa and Class IIb is roughly another year and another several hundred thousand. Misclassifying in your business plan is a serious mistake — and "we'll figure it out at Series A" is not a plan.

Data protection: GDPR and HIPAA sit on top of everything

Medical device classification and data protection compliance are separate, parallel regulatory regimes. Being a Class IIa medical device in the EU does not exempt you from GDPR. Being an FDA-cleared device in the US does not exempt you from HIPAA. The two regimes have overlapping but distinct requirements — and the data protection burden often exceeds the medical device documentation burden in raw effort.

Health data has strict provisions in both jurisdictions (Article 9 GDPR; HIPAA's Privacy and Security Rules), and the AI Act's training data governance requirements interact with GDPR in ways still being clarified. State-level US law (California's CMIA, Washington's My Health My Data Act, others) adds further complexity. A founder building health AI is operating under at least three regulatory regimes — medical device, AI/data protection, and jurisdiction-specific health data law — that need integrated compliance design.

How to make the determination: a practical process

Step 1: Document your intended purpose. Write down, precisely, what your software is intended to do, for whom, in what clinical context, and with what expected clinical decision consequence. Be specific. "AI that helps clinicians" is not an intended purpose. "Software that analyses 12-lead ECG recordings to identify patterns consistent with atrial fibrillation and surfaces flagged recordings for cardiologist review in a cardiology outpatient setting" is an intended purpose. This document is the starting point of every regulatory analysis you will ever do, and getting it precisely right early saves enormous downstream work.

Step 2: Apply the IMDRF framework. Based on your intended purpose, determine your SaMD category (I–IV). This gives you a preliminary risk level.

Step 3: Apply the relevant jurisdiction's classification rules. For EU MDR: apply Rule 11 (and check whether IVDR applies if you're processing IVD outputs). For US: apply FDA's software function guidance and the four-criterion non-device CDS test. For UK: apply the current UK MDR position (substantially aligned with EU MDR, but check MHRA's roadmap). Apply the AI Act overlay for any EU-bound product. Document the analysis in writing.

Step 4: If you're in a grey zone, get a formal opinion. Three formal mechanisms exist: a pre-submission meeting with FDA (Q-Submission programme), a scientific advice request from MHRA, or a classification opinion from an EU notified body (with reference to MDCG borderline guidance). These are not informal consulting; they are formal regulatory channels with documented outcomes. For genuine grey zones, a formal opinion is significantly cheaper than discovering mid-project that your classification analysis was wrong.

Step 5: Consider sandbox programmes for early-stage uncertainty. MHRA AI Airlock and the EU AI Act regulatory sandboxes provide structured environments for early-stage health AI to develop alongside regulators. These are underused, particularly by US-headquartered founders who don't realise they're an option.

Step 6: Design your system for the classification you've determined. If you're a medical device, start building the QMS, documenting design inputs and outputs, and implementing risk management now — not when you're ready to submit. The cost of retrofitting design controls onto an existing product is, in our experience, roughly 3–5× the cost of building them in from the start, and the timeline cost is typically 6–18 months. Programs that treat regulatory infrastructure as a Series-B problem are programs that don't reach Series B.

Where Vector Labs fits

We work with health AI founders and med tech companies on regulatory strategy at three points: classification scoping (figuring out where your product lands and what the regulatory consequences are), regulatory due diligence (assessing in-flight programs or acquisition targets for regulatory exposure), and engineering execution (building the QMS, design controls, technical file, and clinical evaluation infrastructure that a CE mark or FDA submission requires).

If you're early-stage and uncertain whether your algorithm is a medical device, that's the cheapest moment to get the answer right. Get in touch at vector-labs.ai.

For founders past classification — actually building cardiac AI to clinical-grade — see our companion pieces on the engineering reality and the business case. Together, the three articles cover the path from "is my algorithm a medical device?" through to "how do I ship a CE-marked product and build a defensible cardiac AI business?"