"SaMD compliance: a startup guide to FDA and EU MDR"

If you are building a health app, a diagnostic tool, or software that sits anywhere near a clinical workflow, you have probably landed on the acronym SaMD at some point and done one of two things: bookmarked it to read later, or opened a compliance guide and closed it after three pages of acronyms.

This post is the one you actually read. We are going to explain what SaMD means, how the US FDA and EU MDR frameworks each approach it, and -- critically -- what the practical compliance work looks like once you know your software qualifies.

Whether you are building for a US market, a European one, or both, the foundations are more similar than the separate regulatory bodies would have you believe. We will cover both here, so you get the full picture in one place.

What SaMD actually means

SaMD stands for Software as a Medical Device. The term comes from the International Medical Device Regulators Forum (IMDRF) and is the definition both the FDA and the EU regulatory framework have adopted.

The IMDRF definition is worth knowing: SaMD is software intended to be used for a medical purpose without being part of a hardware medical device.

The critical phrase is "intended to be used for a medical purpose." SaMD is not about what your software technically could do. It is about what you say it is for. A piece of software that could theoretically support a clinical decision but is marketed as a general wellness tool is a different regulatory proposition than one whose product page says "supports diagnosis of Type 2 diabetes."

This distinction -- intended purpose -- is the single most important concept in SaMD compliance, in both the US and Europe. Everything else flows from it.

Is your software SaMD? The threshold question

Before you get into FDA versus MDR, you need to answer one question: does your software make medical claims?

Read through your product documentation, your website, and anything you give to users or customers. Then ask:

• Does it claim to diagnose, detect, predict, or screen for a condition?
• Does it support or influence a clinical decision -- prescribing, treatment selection, diagnosis?
• Is it intended for use by or with patients in a clinical context, rather than healthy people in a consumer context?

If you answered yes to any of those, you are likely in SaMD territory under both US and EU frameworks. The threshold questions are similar because both frameworks use the IMDRF definition as their foundation.

If you answered no, you are probably in general wellness or clinical decision support territory that sits outside device regulation. But read your claims carefully. The line is drawn by your language, not your technology -- and it can shift based on how you describe your product on a sales call or a landing page.

The US path: FDA and SaMD

In the United States, SaMD is regulated by the FDA under a combination of statutes and guidance documents that have evolved significantly over the past decade.

What the FDA regulates

The FDA distinguishes between software that is a medical device and software that is not. The 21st Century Cures Act (2016) formally excluded certain software functions from FDA oversight: general wellness software, administrative tools, and clinical decision support that allows clinicians to independently review the basis of a recommendation before acting on it. Everything outside those exclusions is subject to FDA regulation.

The FDA's Digital Health Center of Excellence has published extensive guidance on how it approaches SaMD, largely aligned with the IMDRF framework. In practice, intended use drives the classification.

FDA risk classification

The FDA classifies medical devices -- including SaMD -- into three classes based on risk:

• Class I: Low risk. Most Class I devices are exempt from premarket review. Applies to software with minimal potential for harm if it fails.
• Class II: Moderate risk. Most SaMD falls here. Requires a 510(k) premarket notification, where you demonstrate substantial equivalence to a predicate device already on the market.
• Class III: High risk. Requires a Premarket Approval (PMA), the most rigorous pathway, involving clinical evidence of safety and effectiveness. Applies to SaMD that is life-sustaining or carries a high risk of serious harm.

The main regulatory pathways

For Class II SaMD, the dominant pathway is a 510(k). You are not proving your device is safe and effective from scratch -- you are demonstrating that it is substantially equivalent to a legally marketed predicate device. If no suitable predicate exists, you can go through De Novo classification, which creates a new device type and sets a predicate for future submissions by others.

For Class III, PMA is the pathway. It requires clinical data and is substantially more resource-intensive. Most early-stage software teams only encounter this for genuinely high-risk applications, such as autonomous diagnostic tools for serious or life-threatening conditions.

The EU path: MDR and SaMD

In the European Union, SaMD is regulated under the Medical Device Regulation (MDR 2017/745), which replaced the older Medical Devices Directive in 2021.

What MDR covers

MDR applies the same intended purpose logic the FDA uses. The EU defines a medical device as a product intended to diagnose, prevent, monitor, predict, treat, or alleviate disease or injury. Software that makes no medical claims sits outside its scope. Our earlier post on when software becomes a medical device in the EU walks through the specific questions to ask.

EU risk classification

MDR uses four classes: Class I, IIa, IIb, and III. Software classification is governed primarily by Rule 11 of the MDR classification rules:

• Software intended to provide information that influences decisions with diagnosis or treatment consequences is Class IIa at minimum, rising to IIb if those decisions could lead to serious deterioration or death.
• Software intended to monitor vital physiological processes in real time, where variations could result in immediate danger, is Class IIb.
• Software that directly drives therapy or drug dosing, where errors could cause serious harm, is Class III.
• Most SaMD that does not fall into the higher categories starts at Class IIa.

Class I can be self-certified by the manufacturer. Class IIa and above requires a notified body -- an independent, accredited third-party organisation that reviews your technical documentation and QMS before you can apply the CE mark.

The conformity assessment

For most SaMD, EU compliance culminates in a conformity assessment by a notified body. You submit a technical file covering your clinical evaluation, risk analysis, IEC 62304 documentation, and evidence that your QMS is in order. Notified bodies assess whether your documentation is sufficient. They are not there to help you build it.

This is why getting the foundations in place before you approach a notified body matters so much. Arriving without a coherent audit trail is expensive in both time and money.

What both require: the shared compliance foundations

Here is the part that matters most for startups: regardless of whether you are targeting the US, Europe, or both, the underlying technical compliance work is almost entirely the same.

IEC 62304 -- software lifecycle

IEC 62304 is the international standard for medical device software lifecycle processes. It covers how you develop, maintain, and release your software: requirements documentation, software architecture, unit and integration testing, verification, and change management. Both the FDA and EU notified bodies expect SaMD developers to work in accordance with it.

If you are already building software with a structured process -- documented requirements, test cases, version-controlled releases -- you are doing the right things. IEC 62304 formalises and documents them.

ISO 13485 -- Quality Management System

A QMS is required for both FDA registration and EU MDR conformity. ISO 13485 is the standard that defines what a QMS for a medical device organisation looks like: how you document your processes, control changes, manage suppliers, handle complaints, and run corrective actions.

You need a QMS before you start selling, not as a future project. Our plain-English guide to what a QMS actually involves covers the building blocks without the jargon. For a software team, the core of it is less heavy than it sounds.

ISO 14971 -- Risk management

Every SaMD needs a documented risk analysis. ISO 14971 is the standard that defines the process: identify hazards, estimate probability and severity of harm, document controls, re-evaluate after controls are applied, and maintain the analysis as the product changes.

Risk management is not a one-time activity. It is a living record that spans your product's entire lifecycle. The risk analysis you write before your first release should be updated whenever a significant change goes out.

Requirements traceability

Both frameworks expect you to demonstrate a clear thread from requirement to verification to test evidence to release. Requirements are linked to test cases. Test results are attached to specific versions. Release records capture what changed, what was verified, and who approved it.

Traceability is what auditors and notified bodies most often want to see demonstrated quickly. Teams who cannot produce it -- because it is scattered across GitHub, Jira, and email -- have a hard time in reviews.

Post-market surveillance

Both FDA and EU MDR require a process for monitoring your software after release. EU MDR makes this a formal, documented requirement with defined content: a Post-Market Surveillance plan and periodic safety update reports. The FDA's quality system regulations carry equivalent expectations. In practice this means having a process for logging complaints, monitoring adverse events, and feeding what you learn back into your risk analysis.

The honest take for early-stage teams

Most startups discover they are building SaMD at an inconvenient moment. A potential enterprise customer asks for your technical file. A distribution partner in Germany asks which notified body you use. An investor asks about your FDA classification.

The good news is that you do not need to have completed a 510(k) or notified body assessment at the seed stage. What you need is to be building in a way that makes those submissions achievable. That means documented requirements, a risk analysis in progress, test evidence linked to the requirements it covers, and releases going through a structured approval process.

The cost of getting the foundations right early is low. The cost of retrofitting proper documentation onto a product that has been in production for two years -- under pressure from a customer audit or a regulatory deadline -- is high. The teams who struggle most are the ones who treated compliance as a "later" problem until later arrived.

The standards themselves are not the hard part. They are not as intimidating as they look, and once you understand what they are asking for, most of it maps directly onto things a disciplined software team is already doing. The hard part is producing the documentation -- requirements, risk analysis, release records, traceability -- without it consuming weeks of consultant time or grinding your development process to a halt. That is where AI changes the picture considerably.

Starting somewhere practical

If you are figuring out where to begin:

1. Review your product claims -- website, documentation, pitch deck. Does anything suggest a medical purpose?
2. If yes, determine your risk class under both Rule 11 (EU MDR) and the FDA's device classification database.
3. Identify your regulatory pathway: 510(k) and/or notified body conformity assessment.
4. Get a QMS in place with requirements, verifications, risk analysis, and change control.
5. When you are ready for a formal submission, a regulatory affairs consultant is worth engaging for that specific work -- interpreting how a notified body will read your technical file, or navigating an FDA Q-submission. That engagement is far shorter and cheaper when your documentation already exists and is in order.

Steps 1 through 4 are things you can start today. Step 5 does not need to happen until you are approaching a submission or an enterprise customer audit.

Where QualiHQ fits

QualiHQ is an AI-powered QMS that does the compliance paperwork for you at every step -- so your team is not the one writing it from scratch, and you are not paying a consultant to produce it.

Describe your product and the AI generates your initial requirements, proposes your risk items, and drafts your first risk analysis. As you build, every release goes through a structured approval process with AI-generated release descriptions and automatic checks for missing verifications. Test runs and documentation are attached to the relevant requirements automatically. The full traceability record -- requirements to verifications to test evidence to release -- builds as a natural output of your development process, without anyone having to assemble it manually.

The documentation that traditionally required weeks of consultant workshops arrives in hours. When a notified body or an FDA reviewer asks for your evidence, it is already there.

Start free and see how much of your compliance foundation you can build before anyone charges you anything.

Not sure whether FDA or EU MDR applies to your specific product? In the US, the FDA's Q-Submission programme allows you to request feedback on your regulatory pathway before submission. In Europe, MDCG 2019-11 is the authoritative guidance document on software classification under MDR. For anything with real regulatory stakes, a qualified regulatory affairs consultant is worth the investment early.