Is My App a Medical Device? A Founder’s Classification Guide (2026)

Whether your app is a medical device depends on what you intend it to do, not on the technology you build it with. If your app is meant to diagnose, treat, cure, mitigate, or prevent a disease, or to interpret medical data to drive a clinical decision, regulators will almost certainly treat it as a medical device. If it only stores, displays, or transmits health information, or supports general wellness, it usually is not. The same codebase can land on either side of that line depending on the claims you attach to it.

This guide gives you a three-question test to classify your app under both US and EU rules, shows where common app types typically fall, and tells you what each verdict commits you to next. It is the starting point for everything that follows in Medical Device Software Development, from risk management to regulatory clearance.

Intended use decides everything

Regulators do not classify software by what it is built from. They classify it by its intended purpose, which is what you claim the app does. That intent shows up in your marketing copy, your app store description, your in-app labels, and your instructions for use. Your private engineering intent does not matter. The public claim does.

This is why two apps can share almost identical code and end up in different regulatory worlds. “Track your resting heart rate” is a wellness claim. “Detect atrial fibrillation and alert you to see a doctor” is a medical claim. Same sensor, same signal processing, very different obligations. The US FDA frames intended use as the objective intent expressed by the people responsible for labeling the product, and the EU applies the same logic through its guidance on software.

The practical consequence is that founders routinely pull themselves into regulation by overclaiming. A confident marketing line written to boost conversions can convert a wellness app into a regulated device overnight. Before you classify anything, write down exactly what your app claims to do for a user or a clinician. That single sentence is the input to every decision below.

The US view: how the FDA defines a medical device

Under Section 201(h) of the US Federal Food, Drug, and Cosmetic Act, a device is any article intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease, or intended to affect the structure or function of the body, that does not achieve its primary purpose through chemical action. Software counts. The FDA’s own guidance on determining device status tells you to start by defining your intended use and indications for use, then check whether a product classification already exists.

The 21st Century Cures Act of 2016 carved several software functions out of the device definition. These generally include administrative support for a healthcare facility, software that maintains or encourages a healthy lifestyle unrelated to disease, electronic health records, and software that only transfers, stores, converts formats, or displays data. If your app lives entirely inside those carve-outs, it is not a device under US law.

There is a second layer worth understanding: enforcement discretion. Some software meets the device definition but is low enough risk that the FDA states it does not intend to enforce device requirements. The app is still technically a device, but the practical compliance burden is light. The FDA’s policy for device software functions and mobile medical applications spells out which categories fall where. When a software function does meet the definition and matters to patient safety, the FDA calls it Software as a Medical Device (SaMD), and full requirements apply.

The EU and UK view: MDR, Rule 11, and the MHRA

If you plan to sell in Europe, classify separately. Under the EU Medical Device Regulation 2017/745, software qualifies as a medical device when it has a medical purpose, which mirrors the intended-use principle you already applied for the US. The catch is the risk class.

Classification runs through Annex VIII, and Rule 11 is the one that surprises founders. Standalone medical software that provides information used for diagnostic or treatment decisions frequently lands at Class IIa or higher, and can reach Class IIb or III when a wrong output could cause serious harm or death. That is a materially heavier burden than most US carve-outs. An app that enjoys enforcement discretion in the US can be a fully regulated Class IIa device in the EU. The European Commission’s MDCG 2019-11 guidance (revised June 2025) is the practical reference for qualifying and classifying software, and the revision sharpened Rule 11, stressed a clear statement of intended purpose, and addressed the overlap with the European Health Data Space. The full document is available here.

The UK is now a separate path. After Brexit, the MHRA regulates devices for the Great Britain market on its own timeline, so treat Britain as a third jurisdiction rather than assuming EU status carries over. The takeaway across all three: classify per market, because the same app can be exempt in one and regulated in another.

Why classification breaks mid-build, and how to lock it early

Across more than 300 products shipped in 21 countries, including healthcare platforms like AssureCare that serve 53M+ members, one failure pattern shows up more than any other. Teams classify their app once, at the idea stage, then let the classification silently drift as the product grows. We call it claim creep. A wellness app adds a “risk score.” A monitoring dashboard adds an “alert.” A tracker adds an AI feature that “suggests” something. Each addition feels minor. Together they move the product across the device line without anyone deciding to.

The damage is not the reclassification itself. It is when it happens. Discovering at launch that you are a Class IIa device means retrofitting risk management, a compliant software lifecycle, and a clinical evaluation onto a codebase that was never architected for them. That is the single most expensive way to build regulated software.

Here is the discipline we build into every regulated engagement:

• Write a one-page Classification Memo before any production code. It states the intended purpose in a single sentence, the target markets, the FDA and MDR verdict for each, and the risk class. It is signed off by product and regulatory together.
• Treat every new claim as a classification event. If a feature changes what the app claims to do medically, the memo is revisited before the feature ships, not after.
• Architect for the classification you are most likely to reach, not the one you start at. Traceability, logging, and risk controls are cheap to design in and painful to bolt on.

This is exactly the assessment we run at the front of our AI Velocity Pods, so the classification is settled before the 38-day build clock starts. It is the difference between compliance as a foundation and compliance as an emergency. Explore how we approach Medical Device Software Development for regulated products.

The decision framework: three gates

Most apps can be classified with three sequential questions. Work through them in order. Each “yes” moves you toward device status, and the further you go, the heavier the obligation.

Gate 1: The purpose test

Is the app intended for a medical purpose, meaning to diagnose, treat, monitor, or prevent a disease or condition? Or is it wellness, administrative, or general information? A medical purpose moves you toward device. “Stay active and sleep better” stays out. “Manage your diabetes” moves in.

Gate 2: The function test

Does the app only store, display, or transmit data? Or does it interpret, analyze, calculate, or recommend? Passive handling of data tends to stay out of scope. The moment your app turns data into a clinical conclusion or a recommendation, it moves toward device.

Gate 3: The risk test

If the app is wrong, what happens to the patient? This gate does not usually decide device or not, but it decides how heavily you are regulated. Higher patient risk raises the class and the burden, which is precisely how EU Rule 11 escalates software. A wrong step count is harmless. A wrong insulin dose is not.

You are probably a medical device if…

• You claim the app diagnoses, treats, monitors, or prevents a specific disease or condition.
• It interprets medical data or images and outputs a clinical conclusion or a specific recommendation.
• A wrong output could directly harm a patient’s health.
• It calculates a dose, a diagnosis, or a treatment for an individual patient.

You are probably not a device if…

• It only promotes general wellness with no disease claim.
• It only stores, displays, or transfers data without interpreting it.
• It is administrative software for scheduling, billing, or records.
• Any recommendation can be fully and independently reviewed by a clinician before action.

Classification by app type

Use this as a fast orientation, not a final verdict. Every row can flip based on the exact claims you make, which is why the two walkthroughs below matter more than the table itself.

Walkthrough: the fertility app that flips

An app logs cycle dates and predicts a fertile window. Marketed as “understand your cycle,” it is wellness. Add the claim “prevent pregnancy” and it becomes a contraceptive medical device, because a wrong prediction carries a serious consequence. This is not hypothetical: Natural Cycles was cleared by the FDA as a Class II device through the De Novo pathway and is CE marked as Class IIb in the EU, on the strength of its contraception claim. One line of copy changed the classification and the entire compliance path.

Walkthrough: the symptom checker that depends on its audience

A symptom checker built for clinicians that surfaces possible conditions and shows the reasoning behind each, so the clinician can review it independently, may sit outside the device definition as non-device decision support. The same engine pointed at patients, telling them what they likely have, is a device. The logic did not change. The intended user and the reviewability did.

The gray zones founders get wrong

Wellness versus medical

The line is the diagnostic or treatment claim, not the mere mention of a disease. “Improve your fitness” is wellness. “Manage your hypertension” is medical. The FDA’s General Wellness policy, revised in January 2026, keeps two kinds of claims out of scope: pure lifestyle claims, and claims that link a healthy lifestyle to reducing the risk of a chronic disease where that link is well established. You cross over when you make a disease-specific diagnostic, treatment, or management claim. The 2026 update also lets some noninvasive trackers that estimate parameters like blood pressure or heart rate stay in the wellness category, as long as they avoid diagnostic and treatment claims. Founders lose this one in the marketing department, not the engineering department.

The clinical decision support carve-out

US law excludes certain clinician-facing decision support from the device definition, but only if it meets all four Cures Act criteria. The decisive one is the fourth: the software must let the healthcare professional independently review the basis for its recommendation, so they are not relying primarily on the software to make the call. This is exactly where many AI and machine learning features fail. If a model produces a recommendation the clinician cannot meaningfully interrogate, the carve-out does not apply and you are back to being a device. The FDA’s revised 2026 CDS guidance is the document to read closely here.

“We just move data”

Transferring, storing, and displaying health data is generally out of scope. Adding a layer that interprets or analyzes that data is where you cross the line. A dashboard that shows a patient’s glucose readings is likely fine. The same dashboard that flags a reading as dangerous and tells the user to act is making a clinical judgment. AI features are now the fastest-growing source of accidental device classification. Our guide to FDA compliance for AI medical devices goes deeper here. This is why we treat every new model as a classification event, not just a product feature.

You have classified it. What now?

Your verdict routes you down one of three paths.

If it is likely a medical device

You are now committed to a regulated development lifecycle. Three pillars sit at the center of Medical Device Software Development:

• Risk management under ISO 14971, which runs across the whole product life, not a one-time checklist.
• A compliant software lifecycle under IEC 62304, which governs how you plan, build, verify, and maintain the code.
• A market pathway: FDA clearance in the US, or CE marking under the MDR in the EU.

Before you commit budget, it helps to see how a compliant build comes together in practice. Our step-by-step guide to building a medical app walks through the process, tech stack, and cost drivers.

If it is probably not a device

Do not fully relax. Keep your marketing claims clean so you do not accidentally opt in, revisit the classification the moment you add AI or diagnostic features, and remember that data protection obligations like HIPAA and GDPR apply regardless of device status. A wellness app still handles sensitive health data.

If it lands in a gray zone

Get a formal classification assessment before you write production code. In the US you can request a formal determination from the FDA, but the faster commercial route is an experienced regulatory and engineering partner who has done it before. Reclassifying mid-build is the expensive mistake this entire guide exists to prevent. Related reading: our guide to mHealth app development.

Discover how Ailoitte AI keeps you ahead of risk

Let's Talk

Sunil Kumar

Sunil Kumar is CEO of Ailoitte, an AI-native engineering company building intelligent applications for startups and enterprises. He created the AI Velocity Pods model, delivering production-ready AI products 5× faster than traditional teams. Sunil writes about agentic AI, GenAI strategy, and outcome-based engineering. Connect on LinkedIn