Is It a Medical Device? The Ultimate Classification Guide (EU + US)

Every health tech founder eventually asks some version of the same question: is this thing I'm building actually a medical device, and if so, how heavily regulated is it. The honest answer is almost never a flat yes or no. It depends on what your product claims to do, in which market, described with a precision most teams haven't written down yet. This guide is the single reference for that question across both major systems: the EU's MDR classification logic and the US FDA's device definition, side by side, with a borderline gallery big enough to actually resemble the products founders build.

In short: Whether your product is a regulated medical device depends on its intended purpose, not its technology. In the EU, MDR Rule 11 pushes most decision-supporting software to Class IIa or higher; in the US, analysing patient data to diagnose, treat, monitor, or recommend care likely meets FDA's device definition. This guide walks both systems.

On this page: Why classification is the first decision that prices everything downstream · EU: the medical-purpose test and MDCG decision logic · EU: Rule 11 and the four classes · US: the device definition applied to health AI · US: wellness policy and the CDS exemption · Borderline gallery: 12 real product patterns · When EU and US disagree · From class to plan · FAQ

Why classification is the first decision that prices everything downstream

Founders tend to treat classification as paperwork — a box to check once the product is otherwise built. It's closer to the opposite. Classification is the single variable that determines the shape, cost, and duration of nearly everything that follows, in both the EU and the US, and it does so before you've written a line of technical documentation.

In the EU, your MDR class decides whether you can self-certify (Class I) or need a Notified Body to review your technical file before you can place the device on the market (Class IIa and above). It decides the depth of clinical evidence required — a literature-based equivalence argument at the low end, a full clinical investigation at the high end. Industry figures commonly put Class IIa–III software CE marking at roughly EUR 120,000–300,000 and 12–18 months, though these are industry-cited estimates, not Venitara quotes or outcome guarantees, and the range depends heavily on how mature your technical file and quality management system already are when you start.

In the US, your device status decides whether you need FDA clearance or authorization at all, and if you do, which pathway — 510(k), De Novo, or PMA — realistically fits. Industry figures commonly put 510(k) submissions at roughly USD 150,000–350,000 and 6–12 months from submission to clearance, on top of FDA user fees, again industry-cited context rather than a guarantee. Roughly two-thirds of submissions face some form of hold or additional-information request at some point during review, by one industry estimate — though outright final rejection is a smaller share, commonly cited nearer 10–15%.

The reason this matters more than almost any other early decision is compounding: a founder who classifies late, or classifies against an idealized future version of the product rather than the version actually shipping, doesn't just lose time on paperwork. They lose the ability to sequence fundraising, hiring, and go-to-market around a runway that turns out to be wrong by a year or more. Classification isn't the gate before the "real" work starts — it's the first real work, because it decides what all the subsequent work has to look like.

This pillar exists because that first decision spans two legal systems that ask a similar underlying question — what does this software do, and how significant is a wrong answer — using different tests, different vocabulary, and different consequences. Get comfortable moving between the two. Most founders building for a global market need to answer both, together, from the start.

Start here, not at the end. If you want a first read on where your own product likely sits before working through the logic below, the free MedTech Compass walks through the same questions this guide covers and gives you an AI-generated starting point in minutes. It is not a validated regulatory determination — treat it as a first draft of the conversation you'll want to have with a regulatory expert, not a substitute for one. Start the MedTech Compass →

EU: what makes software a medical device, and who decides?

The EU's starting test is set out in guidance from the Medical Device Coordination Group (MDCG), the body that publishes EU-wide interpretive guidance on MDR. MDCG 2019-11 frames the qualification question in one sentence: software is a medical device when it performs an action on data beyond storage, archival, communication, or simple search, and that action serves a medical purpose defined in Article 2(1) of MDR — diagnosing, preventing, monitoring, predicting, prognosticating, treating, or alleviating disease, injury, or disability, or providing information via examination of the human body.

Two phrases in that test carry all the weight. "Beyond storage, archival, communication, or simple search" separates software that merely holds or displays data — an electronic health record system, a PACS viewer that shows an image without interpreting it — from software that processes, analyses, interprets, or transforms data into new clinical information. "Medical purpose" separates software aimed at a specific diagnostic, therapeutic, monitoring, or predictive function from software that is general-purpose, administrative, or wellness-oriented. Intended purpose is defined by what the manufacturer says the software does — in labelling, instructions for use, and consistently across marketing — not by what a clinician might choose to do with it after the fact.

This is why identical code can sit on either side of the line depending entirely on how it's described. A risk-scoring algorithm marketed as "understand your general health trends" is not automatically a device; the same algorithm marketed as "assess your risk of cardiovascular event" almost certainly is. The test travels with the claim, not the model weights.

A handful of patterns consistently land inside MDR scope: software calculating a risk score used to inform a treatment decision; software flagging an abnormality in an image, ECG trace, or lab result for clinical follow-up; software titrating or recommending a dose based on patient parameters; software triaging patients by likely severity or urgency; software monitoring a physiological parameter and alerting on a clinically significant change. A handful consistently sit outside: software that stores, transmits, or displays data without interpretation; general fitness or wellbeing tracking making no diagnostic or therapeutic claim; scheduling, billing, and administrative systems; general-purpose communication tools used in a healthcare setting.

A scope note before going further: this guide covers software under the MDR. Software with an in vitro diagnostic purpose — analysing specimens such as blood, saliva, or genomic data — falls under the IVDR (Regulation (EU) 2017/746) instead: it classifies under IVDR Annex VIII (Rules 1–7, Classes A–D), an entirely different scheme from the MDR classes discussed below, and requires a performance evaluation rather than an MDR clinical evaluation report. If your software's output derives from examining specimens — a lab-result interpreter, an assay-scoring algorithm, a companion-diagnostic tool — do not apply Rule 11 to it; work from the IVDR's classification rules instead.

Who actually decides? You do, initially — as manufacturer, you classify your own device and document the reasoning in your technical file. A Notified Body then reviews and can challenge that self-assessment during conformity assessment for Class IIa and above. It doesn't invent your classification from scratch, but it can and does reject one it disagrees with. That's why getting a second opinion before formal submission is materially cheaper than discovering a disagreement during review. Escalation routes to the relevant Competent Authority exist, but they're slow and adversarial in practice.

Two MDCG documents do most of the interpretive work here and are worth knowing by name even if you never read them directly: MDCG 2019-11 (the qualification test above) and MDCG 2021-24 (general guidance on classification under Annex VIII, covering all the rules — not Rule 11 alone). Both are guidance, not binding law — a Notified Body isn't strictly required to follow them — but in practice, deviating from published MDCG interpretation without a documented rationale is a common source of technical documentation findings.

MDR Rule 11: Why Software Lands in Class IIa is this pillar's full companion on the qualification test alone: it walks the MDCG 2019-11 logic step by step, works through the wellness/fitness/admin borderline cases in more depth than this chapter has room for, and includes a fillable four-part self-check checklist (output and decision-use, marketing and claims audit, worst-case severity, feature separability) that founders in our review consistently rated the single most directly actionable content across the whole spoke set. If you take one thing from this pillar to work through with a co-founder this week, it's that checklist — go read it in full before you commit to a self-assessment.

EU: what class is my software under Rule 11?

Once software clears the medical-purpose threshold, MDR's Annex VIII takes over: twenty-two classification rules, organized into four groups — non-invasive devices (Rules 1–4), invasive devices (Rules 5–8), active devices (Rules 9–13), and special rules (Rules 14–22) — that sort every device into Class I, IIa, IIb, or III by risk. You work through the rules in order and apply the highest classification any applicable rule assigns; a device can be caught by more than one rule, and the highest result governs.

Rule 11, sitting in the active devices group, is the rule written specifically for software, introduced with MDR to close a gap left by the previous Medical Devices Directive, under which most software defaulted to low-risk Class I. Rule 11 asks what the software's output is used for and how significant that use is:

Here's the practical consequence, and it upends financial models built on older assumptions: for most software with a genuine clinical decision-support function, Class I self-certification is no longer available. Rule 11 was written deliberately to prevent software developers from defaulting to the lightest-touch route, and it has done exactly that. Class IIa is the default outcome for the majority of decision-support software, so Notified Body involvement is the norm for this category, not the exception.

Worth watching, not yet acting on: on 16 December 2025, the European Commission published a proposal (COM(2025) 1023, procedure COD 2025/0404) to simplify MDR and IVDR, which among other things would revise Rule 11 so software starts at Class I and is up-classified based on intended use — the reverse of the mechanism described above. This is early-stage: it still needs European Parliament and Council agreement, and realistic estimates put an amended Rule 11 taking effect no sooner than 2027. It does not change today's binding rule, and the Class IIa default described in this chapter remains the correct basis for classifying software you're bringing to market now.

To be concrete about what each class means in practice:

Class I — self-certification. You compile a technical file, sign a declaration of conformity, and place the CE mark without third-party review. A narrow subset of Class I devices (measuring function, sterile supply, reusable surgical instruments) still needs limited Notified Body involvement for that specific aspect.

Class IIa — Notified Body review, sampling-based. Most diagnostic decision-support software lands here. Industry figures commonly cited: EUR 120,000–300,000 and 12–18 months, though this varies significantly with how mature your technical file and QMS are at the start.

Class IIb — Notified Body review, deeper documentation and manufacturing sampling. Software where a wrong output could cause serious deterioration or require surgical intervention.

Class III — full Notified Body design examination. Software where a wrong output could plausibly cause death or irreversible harm. Longest timeline and highest cost of the four classes.

A few worked examples make the logic concrete rather than abstract. A symptom-checker app suggesting possible conditions and a general urgency level, without directly recommending treatment, typically lands in Class IIa — it provides diagnostic information, but a wrong output is unlikely on its own to cause serious harm before a clinician intervenes. A dosing-calculation tool for a high-risk medication, where an error could require surgical correction, typically lands in Class IIb. An algorithm directly informing treatment for an acute, rapidly progressing condition, where an error could plausibly contribute to death or irreversible harm, is a Class III candidate and should be treated as such from the earliest design stage. A medication reminder app that logs doses and sends notifications without judging clinical appropriateness is Class I or arguably outside MDR entirely.

A common misclassification trap deserves a direct warning here: classifying against an idealized future version of the product, rather than the version actually being placed on the market now. Founders sometimes build evidence requirements for an eighteen-month-away roadmap feature while the version shipping this year is over-specified for its real risk profile. Classify what you're launching now, and revisit formally as the product evolves.

MDR Annex VIII: How Device Classes Are Set is the full spoke on Annex VIII: it walks all four rule groups with worked examples beyond software (non-invasive, invasive, and active-device rules), includes a class/gatekeeper/cost/timeline summary table, and covers common misclassification traps (under-classifying by focusing on technology instead of purpose, ignoring marketing claims, over-classifying out of misplaced caution) in more depth than this chapter has room for. Read it in full if you need the complete Annex VIII picture beyond Rule 11 specifically — for instance, if your product also has a physical or invasive component alongside its software.

US: does my health AI meet FDA's device definition?

The FDA's device definition, from the Federal Food, Drug, and Cosmetic Act, is broad by design: an instrument, apparatus, or software intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease, or intended to affect the structure or function of the body. Software meeting this definition is regulated as Software as a Medical Device, commonly abbreviated SaMD.

For AI specifically, the FDA has been explicit on a point that trips up a lot of technical founders: the presence of machine learning does not itself trigger regulation, and its absence does not exempt a product from it. What matters is functionally the same question MDR asks, phrased differently — what does the software claim to do with patient data, and does that claim fall inside the device definition. A model predicting a patient's risk of a clinical event and presenting that prediction to a clinician for a treatment decision is almost certainly a device. A model recommending today's step goal based on yesterday's activity almost certainly is not.

Health software in the US sorts into three practical buckets. Knowing which one you're in changes what you owe regulators:

General wellness products are exempt under FDA's general wellness policy — low-risk products promoting a healthy lifestyle, with no reference to diagnosing, treating, curing, or preventing a specific disease. This exemption runs on claims, not technology: sophisticated sensors and machine learning can still sit inside general wellness if the claims stay general.

Clinical decision support (CDS) software has a narrower, statutory exemption under the 21st Century Cures Act. All four conditions must be true simultaneously: (1) no direct analysis of medical images, IVD signals, or pattern/signal-acquisition data — this alone disqualifies most AI-driven tools that interpret raw signals; (2) the software displays or analyses medical information already available rather than generating a novel finding from raw signal data; (3) it supports rather than replaces clinical judgment; (4) the clinician can independently review the basis for the recommendation, understanding well enough why the software reached its output that they aren't simply relying on it as their primary basis for a decision. A transparent, rules-based risk calculator usually satisfies condition 4; a trained model whose reasoning isn't exposed in a reviewable way usually doesn't, regardless of its accuracy. The exemption turns on explainability and process, not on how accurate the model is.

Software as a Medical Device (SaMD) is everything else meeting the device definition — software analysing patient data to diagnose, treat, monitor, or recommend care, qualifying for neither exemption above. This is where most substantive health AI products land once they move past pure wellness framing.

Once you've concluded your product is SaMD, pathway follows from predicate availability, not risk category alone: 510(k) if a comparable, legally marketed predicate device exists (FDA clears, doesn't approve, for that intended use); De Novo for genuinely novel low-to-moderate-risk devices with no suitable predicate, resulting in a new device classification; Premarket Approval (PMA) for Class III high-risk devices — the only pathway where "approval" is the technically correct word. A 513(g) request lets you ask FDA directly how it would classify your device before committing, useful when genuine ambiguity remains. If you hear FDA's own class vocabulary elsewhere, the rough bridge is: 510(k) devices are typically Class II, PMA devices are Class III, and a granted De Novo creates a new Class I or Class II classification.

It's also worth knowing that FDA (aligned with the International Medical Device Regulators Forum framework) categorizes SaMD internally along two axes even within a given pathway: the state of the healthcare situation (critical, serious, non-serious) and the significance of the information provided (treats/diagnoses, drives clinical management, or informs clinical management). Two products on the same pathway — say, both pursuing De Novo — can face very different evidentiary expectations if they sit in different risk categories on these axes. Benchmarking your expected evidence burden against a competitor's public 510(k) summary without checking whether you occupy the same risk category is a common and misleading shortcut.

The full spoke on this test is Does My Health AI Need FDA Clearance?, which covers the pathway decision (510(k) vs. De Novo vs. PMA) in more depth, the FDA/EU independence point (a CE mark doesn't help you market in the US and vice versa, though underlying evidence often transfers), and a worked example of intended-use drift over time. Read it in full for the pathway mechanics once you've confirmed device status.

US: am I general wellness, or do I need a claims audit?

FDA's general wellness policy is a two-part test, and a product needs to satisfy both parts to qualify. First, claims: does the product reference a specific disease or condition, or claim to diagnose, treat, cure, mitigate, or prevent disease — as opposed to general health and healthy-lifestyle claims. Second, risk: even where claims stay general, does the product pose safety risks if device-level controls (design controls, adverse event reporting) were absent. Most consumer health technology is low-risk by design, so in FDA's actual enforcement pattern, the claims question does nearly all the deciding work.

The claims audit — how founders talk themselves into device status. This is worth walking through explicitly, because the drift is rarely a single deliberate decision; it accumulates through small, individually defensible copywriting choices. It typically starts with genuinely general wellness language: "track your sleep," "monitor your heart rate during exercise," "understand your activity patterns." As a growth team looks for language that converts better, claims drift toward clinical specificity — a predictable pattern, not a hypothetical one:

• "Identify signs of poor sleep quality" quietly becomes "detect signs of sleep apnoea."
• "Monitor your heart rate" becomes "detect irregular heart rhythms."
• "Track your mood" becomes "screen for signs of depression."
• "Understand how foods affect your energy" becomes "manage your blood sugar."

Each step can feel like a small, defensible improvement in isolation. Collectively, they cross from general wellness into disease-referencing claims. FDA's test looks at the claims as they actually exist across your entire public footprint (marketing site, app store listing, investor materials, press coverage you've solicited), not at your original intended positioning or a disclaimer buried in the terms of service. A disclaimer saying "not intended to diagnose" does not neutralize a prominent claim that a product "detects early signs of" a disease. What matters is the overall impression your claims create, not the fine print appended to them.

The practical discipline that prevents this drift is a standing claims audit: whoever has authority to publish user-facing copy checks new claims against a documented, current list of what your regulatory status actually supports, rather than relying on memory of the product's original positioning. Run this audit now, on your current live copy, across every surface — website, app store listing, investor deck, sales collateral, social media. A product's overall regulatory status is really set by its single most aggressive claim, not its average one.

What happens if you get it wrong is rarely a dramatic enforcement action on day one. FDA action is more commonly triggered by complaints, adverse events, or a company's own public claims than by systematic wellness-app auditing. The more common and more expensive failure mode is a startup that spends two years building on a wellness foundation, only to discover during Series B due diligence that its actual marketing claims drifted into device territory — forcing a scramble to either walk back claims publicly or retroactively build the regulatory infrastructure that should have existed from the point the claims changed.

Wellness App or Medical Device? The FDA Line is the full spoke on this boundary: it runs the claims-drift worked examples across sleep, HRV, mood, and glucose-adjacent products in more depth than this chapter has room for, and includes the complete two-question test walkthrough. Read it in full before you run your own claims audit — it's built specifically to be used as an audit tool against your live copy, not just read once.

The borderline gallery: 12 product patterns classified in both systems

This is the pillar's signature content — the thing no single spoke has room to build. Twelve realistic founder-product patterns, spanning the categories we see most often, classified side by side under both systems. Use it as a first pattern-match against your own product, then confirm with the relevant spoke chapter above and, ideally, an expert conversation before you lock a regulatory strategy.

A few things stand out in this table. Notice how often the deciding variable is a claim or an action, not a technology category — patterns #2/#7 and several others are near-identical hardware with opposite outcomes purely on marketing language. Pattern #10 is the sharpest EU/US divergence in the set: the US CDS exemption has no direct MDR equivalent, so a transparent, explainable tool can be fully exempt in one system and fully regulated in the other. That's not a mistake in either system; it's a genuine structural difference, covered in the next chapter. And pattern #12 is deliberately the least settled: agentic systems that can trigger downstream actions are a live regulatory question in both jurisdictions right now, so any founder building in this space should assume higher scrutiny by default rather than waiting for explicit guidance to catch up.

Two-market classification worksheet. If you're working through where your own product sits, the free MedTech Compass's underlying logic is built around a two-market worksheet — the same EU/US side-by-side structure as the table above, but expanded into a fillable format that walks through your specific claims, data inputs, and outputs against both the Rule 11 test and the FDA device definition simultaneously. Output from the tool is AI-generated, not validated — a first draft to bring into an expert conversation, not a determination to build a submission around. It's available through the free MedTech Compass flow. Start the MedTech Compass →

What if EU and US disagree about my product?

If you worked through the borderline gallery above, you've already seen it: the same product can land at genuinely different regulatory status in the EU and the US. Founders often read that divergence as a sign they've made an error. It's normal — not a red flag.

The two systems are legally independent, built on different statutory logic, and they ask related but not identical questions. MDR's Rule 11 test runs on the significance of the decision-support information provided and the state of the patient, with no categorical exemption for clinical decision support software regardless of how transparent or explainable it is. FDA's framework, by contrast, carves out a specific statutory exemption for CDS software that meets all four conditions — no direct signal/image analysis, displays rather than generates clinical findings, supports rather than replaces judgment, and offers an independently reviewable basis. A rules-based, transparent risk calculator can walk cleanly through all four US conditions while still being squarely inside Rule 11's Class IIa territory in the EU, because the EU test doesn't ask about explainability or clinician independence in the same way — it asks about the significance of the information and the patient's state.

This produces predictable divergence patterns worth knowing in advance, not discovering mid-submission:

Transparent CDS tools often clear the US bar more easily than the EU bar — the US rewards explainability with an exemption; the EU doesn't offer an equivalent categorical exemption at all.

High-acuity AI-driven tools (imaging, signal interpretation) tend to land at comparably high scrutiny in both systems, because both the CDS exemption's condition 1 and MDR's Rule 11 severity test independently flag direct image/signal analysis as high-consequence.

Wellness-framed products tend to align well between systems, because both the MDCG medical-purpose test and FDA's general wellness policy key on the same underlying signal: does the product make a disease-specific or diagnostic/therapeutic claim. A product genuinely outside MDR is very often also genuinely general wellness in the US, and vice versa — this is the pair most likely to agree.

Novel technology categories (agentic systems, LLM-based copilots) are where both systems are actively developing position, which means divergence here reflects genuine regulatory uncertainty on both sides rather than a settled disagreement you're failing to reconcile.

The practical implication is sequencing rather than resolution. You don't need EU and US status to match before you can proceed in either market. You need to know your status in each market independently, and to build your evidence and technical documentation with enough overlap (the same underlying clinical data, verification and validation testing, and quality management system elements) that pursuing both isn't duplicative from scratch. Regulatory equivalence itself doesn't transfer: an FDA clearance doesn't shorten or waive any part of CE marking, and a CE mark doesn't substitute for any part of FDA review. Evidence transfers. Status doesn't.

If your own borderline-gallery pattern match above showed a divergent result between EU and US, that's useful information, not a problem to solve before moving forward — it tells you which market's evidence-building work to prioritize first if you're resource-constrained, and where you can expect to reuse work versus where you'll need materially different evidence for each market.

What happens after I know my class?

Classification is the first decision, not the last one. It's the input that determines the shape of the plan that follows, in both markets.

In the EU, your class determines your conformity route. Class I follows a manufacturer's own declaration of conformity based on an internally compiled technical file — no third-party review. Class IIa, IIb, and III require a Notified Body to review your technical documentation and quality management system, with review depth scaling by class: sampling-based for IIa, deeper documentation and manufacturing review for IIb, full design examination for III. Two roles become central at this stage regardless of exact class: your Person Responsible for Regulatory Compliance (PRRC) under MDR Article 15, and your quality management system, typically built to ISO 13485.

In the US, your device status and pathway determine your submission route — 510(k), De Novo, or PMA — and your quality system obligations under FDA's Quality Management System Regulation (QMSR), effective 2 February 2026, which incorporates ISO 13485 by reference. If you integrated a third-party foundation model into an AI-enabled feature, note that FDA's Predetermined Change Control Plan (PCCP) framework — final guidance specifically for AI/ML-enabled device software issued 4 December 2024 — is the settled mechanism for shipping model updates without a new submission for each change; general (non-AI) device PCCP guidance remains in draft.

If your device uses AI and requires Notified Body assessment in the EU, note one more layer: under the EU AI Act's Article 6(1), that combination makes your AI system automatically high-risk, triggering a further set of obligations (risk management, data governance, technical documentation, human oversight) that largely map onto — and extend — the MDR technical file you're already building, rather than duplicating it from scratch. On timing (updated 25 July 2026): the Digital Omnibus package that postpones the AI Act's high-risk deadlines was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 and enters into force on 27 July 2026. From entry into force, the deferred dates are the legally binding ones — 2 December 2027 for Annex III stand-alone high-risk systems, and 2 August 2028 for high-risk AI in regulated products, including medical devices under Article 6(1) — and the original 2 August 2026 and 2 August 2027 dates are superseded. Plan against the deferred dates, and keep evidence-generation moving inside your MDR work regardless. Separately, and unaffected by that timeline, Article 4 AI literacy has applied since 2 February 2025 with no transitional period. When Medical Device AI Becomes High-Risk covers this overlap and the current deadline picture in full if any part of your product touches AI and Notified Body review.

The common thread across both markets, once class is known: most of the foundational work — a risk management file, a quality management system, a technical documentation structure — is class-agnostic and can start immediately, in parallel with finalizing your exact class, rather than waiting for perfect classification certainty before beginning either. Founders who treat classification as a one-time gate before "real" work begins routinely lose months they didn't need to lose.

Frequently Asked Questions

I genuinely can't tell if my product has a "medical purpose" — what's the fastest way to get unstuck? Write one sentence, in plain language, describing exactly what your product claims to do for the user's health — no technical description, no model architecture, just the claim as a user or clinician would actually read it on your website or app store listing today. That sentence is closer to how both MDCG and FDA will read your intended purpose than any engineering description. If that sentence references a specific disease, condition, diagnosis, or treatment decision, start from the assumption that you're inside scope in at least one system and work the tests in this guide from there.

Does it matter who makes the classification decision — us, or a regulator? In both systems, you classify first, as the manufacturer, and document your reasoning. In the EU, a Notified Body reviews and can challenge your self-assessed class during conformity assessment for Class IIa and above; it doesn't assign your class from a blank sheet, but it can and does reject a classification it disagrees with, and formal appeal routes exist but are slow. In the US, FDA doesn't pre-clear a wellness or CDS-exemption self-assessment — there's no equivalent formal check-in — though a 513(g) request lets you ask FDA directly how it would classify a genuinely ambiguous device before you commit to a pathway.

My product has both a wellness feature and a decision-support feature — does the whole thing get pulled into scope? Usually, yes, in both systems, unless the two features are genuinely separable: distinctly labelled, marketed as distinct products, and technically partitioned rather than bundled into one interface and one purchase decision. Bundling a device-grade feature into an otherwise wellness product doesn't shield the wellness parts, and it doesn't dilute the device-grade parts either. The more restrictive classification tends to govern the product as placed on the market. If separability is something you're considering as a strategy, build the partition deliberately and document why, rather than assuming a features list alone will read as separable to a regulator.

We're not sure our "AI-powered" feature actually meets either country's AI-specific rules — does that matter for basic device classification? Not for the classification question this guide covers. Both the MDCG software test and FDA's device definition apply regardless of whether the underlying technology is a simple rule, a classical statistical model, or a large language model — classification runs on intended purpose and claims, not on technique. Where AI-specific rules do layer on top is the EU AI Act (automatic high-risk status for AI that is itself a Notified-Body-assessed medical device) and, in the US, ordinary FDA scrutiny of your validation evidence for whatever technique you used. Neither changes your underlying device-or-not, which-class-or-bucket answer.

How often should we revisit our classification once we've made an initial determination? Whenever you add a feature, change a claim, or expand your intended population or use context — in both systems. Classification is tied to intended purpose as documented and marketed at a specific point in time, not a permanent attribute of your codebase. A product that evolves without a formal revisit of its classification documentation can drift into a higher class or a different US bucket without anyone having deliberately decided that it should, which is a materially worse position to discover in due diligence or during a regulator's review than catching the drift yourself, on a schedule.

If our classification determination points away from either MDR or the FDA device definition applying, do we need to do anything, or are we just done? Document the determination in writing, with the specific claims and product description you evaluated against, dated. This record is inexpensive to produce now and valuable later — if your product evolves, or if you're asked in due diligence or by an investor's counsel why you concluded your product sits outside scope, a dated, reasoned self-assessment is a materially stronger position than an undocumented assumption, even if the underlying conclusion doesn't change.

Our product is squarely inside device territory in one market and squarely outside it in the other — did we do something wrong? No — this is one of the more common, and more normal, outcomes in this guide's borderline gallery, particularly for transparent, rules-based clinical decision support tools, which the US exempts categorically under the CDS test but the EU does not exempt at all under Rule 11. Divergence reflects genuine structural differences between the two systems' tests, not an error in your self-assessment. Treat it as sequencing information about which market's evidence-building work to prioritize, rather than a discrepancy to resolve before you can move forward in either one.

---

the free MedTech Compass can walk you through the same EU and US questions this guide covers and give you an AI-generated first read on where your product likely sits in both systems, in minutes. It is not a validated regulatory determination, and a decision this consequential to your cost, timeline, and go-to-market sequencing deserves an expert conversation before you commit a submission strategy to it — but it's a genuinely useful first draft of that conversation, and it's the fastest way to turn this guide's logic into something specific to your product. Start the MedTech Compass →

Where next: MDR Rule 11: Why Software Lands in Class IIa · Does My Health AI Need FDA Clearance? · MDR Annex VIII: How Device Classes Are Set · Wellness App or Medical Device? The FDA Line · When Medical Device AI Becomes High-Risk

Related pillar: once you know your class, CE Marking Medical Device Software: Full Route and FDA Clearance for Health Software: Full Route walk the pathway each class or bucket actually leads to.

Find out in minutes where your product likely sits in both the EU and US. Start the MedTech Compass →

Last reviewed 25 July 2026, next review 1 October 2026. This pillar's classification logic is written to mirror the free MedTech Compass tool's intended logic; formal regulatory review of that tool's underlying logic is pending before this content is treated as the live basis for the tool itself — an open item as of this review. Chapters referencing EU AI Act deadlines reflect the Digital Omnibus postponement (published in the Official Journal 24 July 2026; in force from 27 July 2026) — the deferred dates (Annex III 2 December 2027; Article 6(1) medical devices 2 August 2028) are the legally binding ones, superseding the original dates; see AI Act Dates After the Digital Omnibus for live status.