Intended Use vs Indications for Use: What EU MDR Actually Requires

Vague or overly broad intended purpose statements are among the top reasons notified bodies issue queries on technical file submissions. A statement that conflates what a device does with the condition it treats can trigger a full review cycle.

So can one that omits the intended user and either can add months to a CE marking timeline. The terminology itself compounds the problem: EU MDR, FDA and older MDD guidance each use slightly different words for the same underlying concepts.

This raises a practical question:
How do you navigate the difference between intended use vs indications for use, write a statement that passes notified body review and keep it consistent across your entire technical file?

This article maps the terminology across EU and US regulatory frameworks. It then explains what MDCG 2020-6 actually requires for intended use vs indications for use. It walks through the 7 elements a compliant intended purpose statement must cover. Also, it shows how getting those elements right feeds the downstream work on classification, clinical evaluation and usability engineering.

Table of Content

Why These Terms Trip Up Medical Device Teams

The problem starts with terminology that does not align cleanly across regulatory frameworks.

EU MDR 2017/745 uses the term "intended purpose."
FDA uses both "intended use" and "indications for use" as separate concepts with separate documentation.
MDD used "intended purpose" as well. But the EU MDR definition is stricter and the downstream obligations it triggers are heavier.

So teams moving from MDD to MDR often discover their existing statements do not satisfy either framework cleanly. And the same happens for teams building for dual EU/US submission.

Where the Words Collide

Compounding this, the terms sound like they describe the same thing. "Intended use" and "intended purpose" read as synonyms in plain English and "Indications for use" sounds like a subtype of intended use.

In regulatory practice, the relationships are more specific:

The consequences of getting them wrong are not minor.
A statement that is too broad cannot be supported by available clinical evidence.
One that is too narrow may exclude patient populations your device is already serving.

Why the Statement Touches Every Document

The intended purpose statement also has to stay consistent across the technical file: it appears in the labelling, the instructions for use, the clinical evaluation plan, the risk management file and the usability engineering documentation.

Each of those documents anchors to the same statement. So an ambiguity at the source propagates into every document downstream.

-> In short: the confusion between intended use vs indications for use is not just semantic. It cascades into classification, clinical evidence requirements and the entire technical file.

What To Do:

Audit your existing intended purpose statement against the EU MDR Article 2(12) definition before starting any MDR technical file work.
Flag any place in the technical file where the statement is paraphrased rather than quoted directly, inconsistency across documents is a common notified body query trigger.
If you are preparing dual EU/US submissions, map your EU intended purpose against the FDA intended use and indications for use documents before writing either.

How EU MDR Defines Intended Purpose

EU MDR Article 2(12) defines intended purpose as: "the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation."

This definition is broader than most teams expect and it does not just cover what the device does. It also covers everything the manufacturer has stated about the device's use. The same applies to anything implied or allowed to appear in commercial materials.

The Marketing Materials Clause

That last clause is significant, because if your marketing materials describe an unvalidated clinical benefit, that claim becomes part of your intended purpose.

The definition triggers it automatically and notified bodies review promotional materials alongside technical documentation and will query inconsistencies. So getting the intended purpose right requires coordinating between regulatory, clinical, marketing and product teams. Regulatory affairs and the labelling writer alone are not enough.

Intended Purpose Equals Intended Use

MDCG 2020-6 §1.1 clarifies the relationship between intended purpose and intended use explicitly. "Intended purpose" and "intended use" are synonymous in the EU context, so the MDCG treats them as the same concept.

So when you see "intended use" in older EU documentation, it means the same thing. The same applies to guidance that predates the current MDCG papers. Both refer to intended purpose under the current regulation.

-> In short: under EU MDR, intended purpose = intended use. Indications are a sub-component. FDA splits these into two separate documents.

What To Do:

Review all promotional and marketing materials for your device, anything that describes a clinical use becomes part of the intended purpose by definition.
Align your regulatory team with marketing on a single approved statement before writing any technical file documents.
If building for FDA as well as EU MDR, draft the EU intended purpose first, then decompose it into FDA's intended use and indications for use sections separately.

What Indications for Use Means Under MDCG 2020-6

MDCG 2020-6 §1.1 defines "indication" as: "the clinical condition to be diagnosed, prevented, monitored, treated, alleviated, compensated for, replaced, modified, or controlled by the medical device."

The indication answers a specific question. For which clinical condition is the device intended?

This is narrower than intended purpose. Intended purpose describes what the device does and how and the indication specifies the pathology or health problem it is addressing.

When a Device Has No Indication

Importantly, not all devices have an indication, which MDCG 2020-6 §1.1 is explicit on. For example: devices intended for disinfection or sterilisation of other devices do not have an indication. There is no clinical condition being treated.

The same logic applies to certain single-use accessories and procedural tools. For those devices, the purpose is to enable a procedure rather than address a condition. So the intended purpose statement describes the medical procedure context rather than a clinical indication.

Scoping the Indication to the Evidence

Where an indication does apply, it should be as specific as the available clinical evidence allows. So "treatment of cardiovascular conditions" is too broad if the evidence only covers one specific arrhythmia indication. A notified body will check that the claimed indication is supported by the evidence cited.

Broad indications create an evidence gap and narrow ones limit commercial scope. Finding the right level of specificity is a clinical and regulatory judgement call. It is not just a drafting exercise.

The FDA Comparison

One further point on the FDA comparison. What FDA calls "indications for use" in a 510(k) is closely equivalent to the EU "indication." But the FDA statement also includes patient population and anatomical site details.

EU MDR handles those as separate elements of the intended purpose, so a direct copy-paste from an FDA indications for use into an EU intended purpose document is almost never appropriate.

-> In short: indications for use = the clinical condition being addressed. Not every device needs one. Where it does apply, it must be matched by available clinical evidence.

What To Do:

Determine whether your device has a clinical indication at all, or whether it is a procedural/enabling device with only a medical purpose and no specific condition being treated.
Scope the indication to match your clinical evidence, not broader than the data supports, not narrower than the commercial use case requires.
Do not copy FDA indications for use text directly into an EU intended purpose statement. Map the elements explicitly.

The 7 Elements of a Compliant Intended Purpose Statement

MDCG 2020-6 §1.2 sets out the elements a compliant intended purpose statement must address and these go beyond a short functional description.

Each element affects which regulatory requirements apply to the device.
It also gives the clinical evaluation team the scope to plan the evidence work.
All 7 must be addressed in the statement.
Or each must be explicitly noted as not applicable with a justification.

Elements 1 to 3: Purpose, Indication and Population

The medical purpose (element 1) describes what the device does: choices include diagnose, treat, monitor, alleviate, compensate for, replace, modify or control a function.
The indication (element 2) describes the clinical condition, if one applies.
The patient population (element 3) scopes who the device is for. That includes age ranges, sex where relevant, comorbidities and contraindications.

Together these three elements define the clinical scope and also determine which clinical data is relevant to the evaluation.

Element 4: Intended User

The intended user (element 4) is frequently omitted from first-draft statements. The user type drives the usability engineering requirements under Annex I §5. That depends on whether the device is operated by a trained clinician, a lay person or a self-monitoring patient.

A device intended for lay use requires a full usability engineering process. That includes formative and summative evaluation with lay users. Getting this element wrong means the usability file is designed for the wrong population.

Element 5: Anatomical Site

The anatomical site (element 5) is the most classification-sensitive element and EU MDR Annex VIII classification rules are heavily anatomical. A device that contacts the central nervous system classifies differently from one that does not.

A device placed in the central circulatory system faces different rules than one used externally. The intended purpose statement must name the site clearly since a notified body will use that detail to verify the classification claimed in the technical file.

Elements 6 and 7: Benefit and Mode of Action

Clinical benefit (element 6) must be a benefit the device can demonstrably deliver. The statement should describe what positive effect the patient or user experiences from correct use of the device.

Mode of action (element 7) describes how the device achieves that effect: mechanically, as software, chemically or biologically. For software devices, this is where the Rule 11 SaMD classification logic intersects with the intended purpose statement directly.

-> In short: all 7 elements must appear in the intended purpose statement or be explicitly justified as not applicable. Missing even one creates a gap a notified body will find.

What To Do:

Use the 7-element list as a review checklist when drafting or auditing your intended purpose statement.
For elements that do not apply (e.g. no indication for a sterilisation device), write an explicit "not applicable" note with a one-sentence rationale rather than leaving a gap.
Circulate the completed statement to both clinical evaluation and usability engineering leads before finalising, each team relies on a different subset of the 7 elements.

How Your Intended Purpose Statement Locks Downstream Obligations

The intended purpose statement is the first document a notified body reads and the one everything else in the technical file references. Getting intended use vs indications for use right at this stage determines the scope of every major regulatory workstream that follows. Four of those downstream obligations are particularly sensitive.

1. Device Classification

EU MDR Annex VIII classification rules use the intended purpose to determine device class. Rule 11 governs software as a medical device. It asks whether the software provides information that drives clinical decisions with serious consequences. That question can only be answered against the intended purpose as written.

Three elements feed directly into the classification rules.

Those are anatomical scope (element 5)
patient population (element 3)
medical purpose (element 1)

A statement with a broader anatomical scope than needed can push the device into a higher risk class unnecessarily.

2. Clinical Evaluation Scope

The clinical evaluation plan is scoped against the intended purpose. First the clinical evaluator defines the clinical questions and the evidence required. Then the scope follows from what the device claims to do and for whom.

A vague or overly broad indication creates an open-ended evidence requirement that is hard to satisfy, while a precise indication scoped to available literature and clinical data gives the evaluation a clear endpoint. It also gives a realistic evidence pathway.

So the quality of the intended purpose statement directly determines how straightforward the clinical evaluation will be.

3. Usability Engineering and 4. GSPR

Annex I §5 of EU MDR requires that devices be designed to take into account the user context which covers technical knowledge, experience, education, training and use environment of the intended users. All of that starts with element 4 of the intended purpose.

The intended user must be named. Also, the General Safety and Performance Requirements are filtered by the intended purpose. For example: a device intended for implantation faces different GSPR requirements than an external monitoring device. So the intended purpose statement sets the GSPR checklist scope for the entire design and verification process.

-> In short: the intended purpose statement is the root document for classification, clinical evaluation scope, usability engineering and GSPR compliance. Getting it right at the start saves significant rework later.

What To Do:

Run a classification exercise as soon as the intended purpose is drafted, use the statement to work through the Annex VIII rules and check the class matches your product roadmap.
Give the draft intended purpose to your clinical evaluator before starting the clinical evaluation plan, any ambiguity in scope needs resolving at this stage, not halfway through a literature search.
Map the intended purpose against your GSPR checklist to confirm which requirements are in scope before design verification begins.

Common Mistakes Teams Make When Drafting These Statements

Teams working through intended use vs indications for use for the first time tend to make a predictable set of mistakes. Each one creates a specific problem in the technical file or at notified body review. Here are the ones that come up most consistently.

1. Writing a Marketing Description Instead of a Regulatory Statement

The intended purpose statement is a regulatory document, not a product pitch. Phrases like "transforms patient outcomes through AI" or "provides actionable insights" do not satisfy the MDCG 2020-6 requirements and will be flagged immediately. The statement needs the 7 elements, written plainly and a good intended purpose statement reads like a specification.

2. Scoping the Indication Broader Than the Evidence Supports

Writing a broad indication feels like it expands commercial opportunity and creates an evidence gap. The clinical evaluation cannot close that gap with available data, so a notified body will check that every claimed indication is supported by clinical evidence in the technical file.

If the evidence only covers one patient population or one clinical setting, the indication needs to reflect that and only broadening it later requires a new clinical evaluation cycle.

3. Omitting the Intended User from the Statement

Many first drafts describe the device function and the clinical condition but say nothing about who operates the device. This is the most common missing element in intended purpose statements reviewed by notified bodies.

Omitting the intended user does create a documentation gap and the usability engineering file is designed without a defined user group, which makes the summative evaluation results difficult to interpret and accept.

4. Not Keeping the Statement Consistent Across Documents

The intended purpose appears in five technical-file documents. Those are:

the labelling
the IFU
the clinical evaluation
the risk management file
the usability engineering documentation

Teams working on those documents in parallel often paraphrase the statement rather than quoting it directly. The paraphrases diverge over time and a notified body reviewing the full technical file will check for consistency. It will query any version that introduces new scope, omits an element or contradicts the labelling version.

-> In short: intended use vs indications for use errors almost always fall into one of four patterns: marketing language, over-scoped indications, missing user definition, or cross-document inconsistency.

What To Do:

Establish one approved version of the intended purpose statement at the start of the MDR project and reference it by document and version number in every technical file document that uses it.
Run the statement through the 7-element checklist before submitting any technical file document to a notified body.
Have a regulatory affairs reviewer who did not write the statement read it against your clinical evidence summary to verify the indication scope matches the data available.

FAQs: Intended Use vs Indications for Use Questions Teams Ask

Q1: Are intended use and intended purpose the same thing under EU MDR?

A1: Yes. MDCG 2020-6 §1.1 explicitly states that "intended purpose" and "intended use" are synonymous in the EU MDR context. EU MDR 2017/745 Article 2(12) uses "intended purpose" as the defined term. But older EU documentation and many manufacturers still use "intended use" interchangeably. For practical purposes in a technical file, the two terms refer to the same concept. The key difference is the FDA comparison, where, "intended use" and "indications for use" are two separate documents with separate regulatory requirements.

Q2: Does every medical device need indications for use?

A2: No. MDCG 2020-6 §1.1 states that not all devices have an indication. Devices intended for disinfection or sterilisation of other devices are one example and no clinical indication applies to them. Procedural tools used across many conditions without treating a specific pathology may also have no indication. For those devices, the intended purpose statement describes the medical procedure context and the device type rather than a clinical condition. The absence of an indication must be noted explicitly in the technical file with a brief justification.

Q3: How does the intended purpose statement affect device classification?

A3: Directly. EU MDR Annex VIII classification rules reference the intended purpose at multiple points: anatomical site, patient population, medical purpose and mode of action all feed into specific rules. Rule 11 governs software devices and it asks whether the software provides information used in clinical decision-making with serious consequences. That question is answered against the intended purpose as written. A statement that describes a broader anatomical scope or clinical function than the device delivers can push it into a higher classification. The heavier conformity assessment obligations follow automatically.

Q4: Can we use our FDA indications for use statement for an EU MDR submission?

A4: Not directly. FDA's indications for use statement is a specific document required under 21 CFR 807.87(e). It is formatted for a 510(k) submission. The EU intended purpose statement must cover all 7 elements from MDCG 2020-6 §1.2. Those include intended user, mode of action and clinical benefit. FDA's indications for use covers the clinical condition and patient population elements only and the EU intended purpose requires more. The safest approach is to draft the EU intended purpose independently using the 7-element structure. Then extract the equivalent content for the FDA-specific documents.

Closing Thoughts

The distinction between intended use vs indications for use is worth understanding precisely. The intended purpose statement is where your MDR technical file starts. Classification, clinical evaluation scope, usability engineering and the full GSPR checklist all follow from it. A vague, inconsistent or incomplete statement creates queries at notified body review and also creates rework across the entire file. Getting it right the first time is the most efficient investment a device team can make at the start of an MDR project. Use the 7-element structure from MDCG 2020-6.

If you are working through this for a new EU submission or an MDD transition, our MDR Triage Sprint covers intended purpose, classification and technical file scope in a single engagement.