US vs EU medical device classification: what founders need to know

Start with the intended purpose

Before asking “which class?”, describe what the product actually does, who uses it, which patients it serves and which decisions its output supports. Device qualification asks whether the product falls within device regulation. Classification is the next question: which risk class and regulatory controls apply?

A medical claim, a new user population or a different clinical workflow can change the analysis. For software, assess the individual functions rather than treating every feature in an application as one medical device. European Commission software guidance separates qualification from classification and should be read alongside the legislation.

This comparison concerns medical devices under the EU Medical Device Regulation (MDR), with particular attention to software. In vitro diagnostic devices follow the separate IVDR framework; do not apply the MDR classes below to an IVD.

Sources: FDA: Classify Your Medical Device; EU MDR: Article 51, Article 52 and Annex VIII; European Commission: MDCG 2019-11 rev.1 software guidance (June 2025)

Two systems, different classification logic

The FDA uses Classes I, II and III. Class I devices are subject to general controls; Class II adds special controls; Class III generally requires premarket approval. Finding the relevant FDA classification regulation and product code is a practical starting point. The intended use and characteristics of the device matter.

The EU MDR uses Classes I, IIa, IIb and III. Annex VIII contains classification rules based on intended purpose and the applicable risks. The matching number does not establish equivalence: a US Class II device is not automatically EU Class IIa or IIb.

Sources: FDA: Classify Your Medical Device; EU MDR: Article 51, Article 52 and Annex VIII

Why EU Rule 11 matters for software

Under MDR Annex VIII Rule 11, software providing information used for diagnostic or therapeutic decisions is generally Class IIa. It moves to IIb when those decisions may cause serious deterioration in health or a surgical intervention, and to III when they may cause death or irreversible deterioration in health.

Software monitoring physiological processes is generally IIa; monitoring vital physiological parameters can be IIb where variations could create immediate danger. Other software covered by Rule 11 is Class I. Qualification and other applicable rules still matter, including the rules for software that drives or influences another device.

For an AI ECG rhythm analyzer, “it uses AI” is not enough to assign a class. Define whether it merely displays data, detects a rhythm, supports diagnosis or triggers urgent treatment. The consequences of a wrong result and the intended clinical use require a product-specific assessment in each market.

Sources: EU MDR: Article 51, Article 52 and Annex VIII; European Commission: MDCG 2019-11 rev.1 software guidance (June 2025)

Classification is not the whole route to market

A US 510(k) usually relies on demonstrating substantial equivalence to a legally marketed predicate. Some devices are exempt, subject to the applicable limitations. De Novo provides a route for certain novel devices without a predicate to be classified into Class I or II. Do not infer the submission pathway from the class label alone.

In the EU, CE marking follows the applicable conformity-assessment procedure. Notified-body involvement generally applies to IIa, IIb and III, and to particular aspects of some Class I devices, such as sterile or measuring devices and reusable surgical instruments. FDA clearance and CE marking are different regulatory outcomes.

Sources: EU MDR: Article 51, Article 52 and Annex VIII; FDA: Premarket Notification 510(k); FDA: De Novo classification database and overview

What to prepare before seeking advice

Our practical recommendation is to maintain one short classification memo per market. This makes assumptions visible before the team commits to a launch schedule or an investor milestone.

• Write a precise intended-purpose statement, including users, population, clinical setting and output.
• List each medical software function and the consequence of an incorrect result.
• Record candidate FDA product codes and EU rules, with the evidence and unresolved questions.
• Separate classification, submission or conformity-assessment route, and the evidence still needed.
• Have a qualified regulatory professional review the rationale before relying on it for a filing or launch.