Write the intended purpose narrow enough that a Notified Body reviewer can read it once and land on a single Annex VIII classification rule without guessing, and wide enough that the product roadmap you actually want to run over the next two years does not require rewriting the paragraph and retriggering change control. The sweet spot is one controlled paragraph that names the device, the medical condition, the clinical verb from Article 2(1), the patient population, the intended user, and the environment of use — with no adjectives, no features, no brand positioning, and nothing that locks in implementation choices you still want the freedom to change.

By Felix Lenhard and Tibor Zechmeister. Last updated 10 April 2026.

TL;DR

  • 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." That sentence is the legal anchor for every classification, clinical evaluation, and labelling decision you make.
  • The specificity side of the tension comes from Article 51 and Annex VIII: classification rules read the intended purpose literally and will route the device to a different class if the wording is ambiguous.
  • The flexibility side of the tension comes from the product roadmap: every word that names a specific implementation choice, a specific feature, or a specific performance number locks that choice into the file and makes later change expensive.
  • The rule is simple: specify the medical claim tightly, and leave the implementation loose. Name the condition, the verb, the population, the user, and the environment. Do not name the algorithm, the hardware revision, the accuracy number, or the brand language.
  • Two kinds of mistakes dominate the failure modes. Over-constraining kills product flexibility and triggers change control on trivia. Under-constraining invites the Notified Body to choose a worse classification rule than you could have defended with tighter wording.
  • The revision discipline is the hedge: draft, test against Annex VIII, test against the roadmap, cut, rewrite, re-test, freeze. The afternoon it takes is the cheapest insurance the project buys.

Why this is the hardest paragraph a founder writes

In a MedTech startup there is exactly one paragraph that decides the shape of the entire regulatory project, the shape of the next two years of product work, and the shape of every claim the sales team is ever allowed to make. That paragraph is the intended purpose. Felix has watched founders spend six months on a pitch deck and six minutes on their Zweckbestimmung, and then spend the next two years paying for that ratio.

The paragraph is hard because it sits on the single biggest tension in MedTech product work. On one side, the regulation wants it narrow — narrow enough that an auditor can read the paragraph and classify the device without guessing. On the other side, the product roadmap wants it loose — loose enough that the next twelve sprints of engineering, clinical work, and market discovery do not require a change notification to the Notified Body every time the team learns something new. Most founders feel only one side of this tension at a time. They either write something so vague that the classification is unstable, or they write something so specific that the file has to be reopened every quarter because the product moved and the paragraph did not.

The path through is not a compromise. It is a separation. The parts of the paragraph that the regulation reads literally — the condition, the verb, the population, the user, the environment — should be tight. The parts that belong to the implementation — the specific algorithm, the exact performance metric, the feature list, the hardware revision — should not be in the paragraph at all. When founders confuse the two layers, they either over-constrain on the implementation side or under-constrain on the regulatory side. Either way, they pay.

The tension between specificity and flexibility

Specificity and flexibility sound like opposites. In the intended purpose paragraph they are not — they sit on different axes of the same sentence, and the skill is knowing which words belong on which axis.

Specificity lives in the regulatory axis. The MDR keys classification, clinical evaluation, and labelling off words with precise meaning: "adults," "monitoring," "acute ischaemic stroke," "home environment," "trained healthcare professional." These words trigger specific obligations under Annex VIII, Annex XIV, and Annex I. They need to be correct and stable. Changing them is a significant change that propagates through the file.

Flexibility lives in the implementation axis. This is everything about how the device actually achieves its effect — the algorithm, the sensors, the number of measurement channels, the user interface, the exact accuracy threshold, the chosen modality. These are engineering decisions, and engineering decisions will change as the product matures. A paragraph that hard-codes implementation details into the intended purpose is a paragraph that is going to be rewritten every release, because the implementation will move and the paragraph will not keep up.

The rule is to separate the two axes explicitly. Ask, of every word you are tempted to include: does this word belong to the medical claim, or does it belong to the implementation? If it belongs to the medical claim, it stays, and it has to be correct. If it belongs to the implementation, it goes elsewhere in the technical file — the device description in Annex II Section 1, the GSPR mapping, the risk file, the design inputs — but not into the intended purpose paragraph. The paragraph is not where you describe the device. It is where you describe what the device is for.

What drives class — the tight side of the paragraph

Article 51 of Regulation (EU) 2017/745 routes every device through the classification rules in Annex VIII. Those rules are sensitive to specific words in the intended purpose. A few examples worth holding in your head when you draft.

The verb from Article 2(1) — diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation — selects different classification rules. "Monitoring" of vital physiological parameters is not the same rule family as "diagnosis," and neither is the same as "prevention." Pick the verb that actually matches what the device does, and use only that verb. Mixing verbs in one paragraph is a common way to broaden the classification unnecessarily.

The nature of the condition matters. A device "used in connection with" a life-threatening condition is read differently from a device used for general wellbeing. Invasive vs. non-invasive, active vs. passive, duration of contact, contact with the central circulatory or central nervous system — these are all read directly from the intended purpose into the classification rules. Each one changes the class.

The patient population matters. Neonates, children, pregnant women, and specific vulnerable groups trigger additional rules and additional evidence burden. If the device is not intended for a vulnerable population, say so. If it is, say so. Do not leave the population implicit — the implicit version is usually read as "anyone," which is almost never what the manufacturer meant.

The intended user matters. "Healthcare professional," "trained lay user," "patient as self-user" all have downstream consequences for usability engineering under IEC 62366-1 and for labelling. The classification rules themselves sometimes key off the user.

The environment of use matters. "Hospital setting" is a different obligation stack from "home use." If you write the paragraph without naming the environment, the default assumption the auditor makes will almost always be the more burdensome one.

These five elements — verb, condition, population, user, environment — are the tight side. They are the parts you specify with care and defend with evidence. They are the parts you do not change without running change control.

What drives clinical evidence — the other tight side

Article 61 and Annex XIV require clinical evidence sufficient to demonstrate conformity for the intended purpose. Every word on the tight side above is a word the clinical evaluation has to address. That is why you do not extend the tight side beyond what you can actually evidence.

Felix has seen it both ways. Founders who wrote "adults and children aged 2 years and older" in their intended purpose because they wanted the broadest addressable market, and then discovered that paediatric evidence was going to cost them a full additional arm on the clinical investigation and eighteen months they did not have. Founders who wrote "used for monitoring and diagnosis" because both verbs felt nice, and then discovered that "diagnosis" triggered a higher class and a new clinical evidence requirement they never intended to take on.

The rule on the clinical evidence side is: every word on the tight side has to be evidenced. If you cannot afford the evidence for a word, the word does not belong in the paragraph yet. You can add it later, through a change notification, when you have the evidence. You cannot put it in now and back-fill the evidence during the audit.

This is where the Subtract to Ship discipline from the Subtract to Ship framework for MDR bites hardest. The Purpose Pass is the place where founders get one chance, before the technical file exists, to trim the tight side to the narrowest honest statement of what the device is for. Every word you leave in is a word the clinical evaluation has to defend. Every word you take out is a clinical evaluation dollar you keep.

How to test your wording

Before you freeze the paragraph, run it through four tests. Each test takes a few minutes. All four together take under an hour. They are the cheapest quality gate in the entire regulatory project.

The Annex VIII test. Hand the paragraph to someone who knows the classification rules but has never seen your product. Ask them to pick the applicable rule from Annex VIII and justify it using only the paragraph. If they pick the rule you expect, the paragraph is specific enough on the regulatory axis. If they pick a different rule, or cannot pick one confidently, the paragraph is too vague on the tight side and you rewrite.

The roadmap test. Pull up your twelve-to-twenty-four-month product roadmap. Walk through each planned change — new feature, new sensor, new user group, new environment, new indication, new algorithm version. For each one, ask: does this change require rewriting the intended purpose? If a planned change forces a rewrite, either that change is actually a significant change and you are going to pay the change control cost anyway — or the paragraph is over-constrained on the implementation axis and you can loosen it without losing regulatory specificity.

The four-sources coherence test. Read the paragraph, then read the website product page, then read the pitch deck, then read the draft IFU. All four are sources of intended purpose under Article 2(12). If any of the four tells a different story — a broader claim on the website, a different population in the deck, a medical verb in the IFU that the paragraph does not contain — you have an Article 2(12) problem and the file has not been written yet. Fix it now, before anything downstream depends on the paragraph.

The read-aloud test. Read the paragraph out loud. If you stumble, if a sentence feels long, if you find yourself wanting to paraphrase it, the paragraph is not stable enough to be the controlled source of intended purpose. A stable paragraph can be quoted from memory by the founder, the regulatory lead, and ideally the head of engineering. If the team paraphrases it instead of quoting it, the paraphrases will drift and the Article 2(12) coherence will drift with them.

Common over-constraining mistakes

Over-constraining is the failure mode Felix sees most often in founders who have been told "write it narrow." They take the instruction too literally and bake implementation details into the paragraph.

  • Naming the algorithm. "Using a convolutional neural network based on the MobileNetV3 architecture" is an engineering choice, not a medical claim. When the team moves to a newer architecture next quarter, the paragraph forces a change notification for a change the classification does not care about.
  • Naming the exact accuracy threshold. "Detects X with a sensitivity of 94%" locks a performance number into the legal definition of the device. Performance numbers belong in the clinical evaluation and in the IFU performance claims section. They do not belong in the intended purpose.
  • Naming specific hardware revisions. "On the MkIII sensor platform" ties the paragraph to a hardware generation that will be obsolete in eighteen months.
  • Over-specifying the clinical workflow. "Used immediately after induction of anaesthesia and before the first incision" is a level of workflow detail that belongs in the IFU, not in the intended purpose. If the workflow shifts by one step, the paragraph is wrong.
  • Brand language and adjectives. "Innovative," "next-generation," "AI-powered," "best-in-class." None of these are auditable. They do not help classification and they do not help the clinical evaluation. They are sales language in a legal document, and they are a liability the moment anyone asks you to defend them.
  • Feature lists. Any sentence that starts "which includes" and lists features is over-constraining. Features change. The paragraph does not.

Every over-constraint on the implementation axis buys nothing on the regulatory axis and costs you flexibility. Cut all of them.

Common under-constraining mistakes

Under-constraining is the opposite failure mode. Founders who have been told "leave yourself room" write something so vague that the classification is unstable and the clinical evaluation cannot be scoped.

  • Missing the verb. No verb from Article 2(1) at all. The paragraph describes a device and a field but never says what the device is for in the MDR sense. Auditors who cannot find the verb pick one for you, and it is usually not the one you wanted.
  • Mixed verbs. "Monitoring, diagnosis, and assistance in the management of" packs three different regulatory consequences into one sentence. Pick the one you can evidence and cut the others, or split them into clearly scoped use cases.
  • No population. "For patients with cardiovascular disease" is a planet, not a population. The classification rules and the clinical evaluation need age range, clinical status, inclusion and exclusion criteria at the level the evidence will be collected.
  • No environment. A device that could run in a hospital, a clinic, a pharmacy, or a home has four different obligation stacks. If the paragraph does not pick one (or explicitly list the included ones), the auditor defaults to the broadest.
  • No contraindications. A paragraph that lists only what the device is for, without saying what it is not for, leaves the outer edge of the scope undefined. Auditors and users fill the gap, usually in directions the manufacturer did not intend.
  • Marketing language where the medical claim belongs. "Empowers clinicians to make better decisions" is not a medical claim. It is a slogan. The regulator reads slogans as evidence of a medical claim anyway, but a broader and vaguer one than you would have written deliberately.

Under-constraining looks like freedom. It is not. It is a delegated decision — you are letting the Notified Body and the classification rules make the choice for you, and their default is always the more burdensome interpretation.

Tibor's hardware-software defence — specificity as a classification tool

One case Tibor worked on makes the specificity argument concrete. A combined hardware-and-software device arrived with a classification question that was genuinely arguable. The software side of the device was clearly Class IIa — no dispute. The hardware side was the open question: was it a Class I device, or a Class I device with measurement function, which triggers additional conformity assessment requirements under the Annex VIII rules?

The resolution did not come from rewriting the engineering. It came from rewriting the intended purpose with surgical care on the tight side. The paragraph named exactly what the hardware was for, exactly what clinical verb applied to it, and exactly what it was not for — including an explicit statement that the hardware did not perform a measurement in the Annex VIII sense. The classification rationale then walked the auditor through Annex VIII rule by rule, landing on the Class I argument with the paragraph as the evidence.

The Notified Body accepted the argument. The device certified under the lighter conformity assessment route. Months of work, tens of thousands of euros, and weeks of Notified Body time were saved — not by gaming anything, but by writing the intended purpose tightly enough that the classification rules had only one honest answer.

This is what the specificity side of the tension is for. Not to make the file smaller for its own sake, but to make the classification defensible and repeatable. A tight, well-drafted paragraph is an asset in every conversation with the Notified Body. A loose one is a liability.

The Graz wellness pivot — specificity in the other direction

The same discipline pointed the other way saved another company years. A Graz founder had spent months building an MDR strategy for a product with a Notified Body shortlist, a draft technical file outline, and a clinical evaluation plan. We ran the Purpose Pass on their intended purpose and found that the hardware and software did not actually require MDR treatment — the words around them did.

A small, deliberate revision of the intended purpose removed the medical verbs that the claims were triggering, kept everything the product honestly did, and re-framed the product as a wellness device. The technology did not change. The software did not change. The set of sentences the manufacturer was willing to stand behind on the label, in the IFU, and in the promotional materials — those changed. The revised intended purpose no longer met the definition of a medical device under MDR Article 2(1), and the regulation genuinely did not apply.

The product entered the market under consumer product legislation much faster than the original MDR plan allowed. This is the other edge of the specificity discipline. The words in the paragraph decide which regulation owns the product. When the medical verbs are deliberate, the paragraph can be narrow enough to avoid the MDR entirely — not through evasion, but through honest narrowing to what the product actually is.

Tibor Story 4 and Tibor Story 5 sit on the same axis. One uses specificity to classify down inside MDR. The other uses specificity to classify out of MDR entirely. Both depend on the founder taking the intended purpose paragraph seriously enough to write it deliberately.

The revision discipline

The paragraph does not come out right on the first draft. It never has, in any project we have run. The revision discipline is the process that gets it from first draft to frozen canonical version in an afternoon of focused work.

Draft. Write the first version against a checklist: device category, condition, verb, population, user, environment, principle of operation (one clause), contraindications. No adjectives. No features. No performance numbers. Three to six sentences.

Test against Annex VIII. Hand the draft to a classification check. If the rule is unambiguous and matches what you expect, move on. If it is ambiguous, identify the ambiguous words and rewrite them.

Test against the roadmap. Walk the next twenty-four months of product plans through the paragraph. Flag any planned change that would require rewriting the paragraph. For each flag, decide whether the change is actually significant (in which case the paragraph is fine and you will pay change control when it happens) or whether the paragraph is over-constrained (in which case you loosen the implementation axis).

Test against the clinical evidence plan. Every tight-side word has to be evidenced. Walk the clinical evaluation plan against the paragraph. If any word in the paragraph is not covered by the evidence plan, either add it to the plan or take the word out of the paragraph.

Test against the four Article 2(12) sources. Read the paragraph, the website, the deck, and the draft IFU side by side. Align them. If alignment requires the paragraph to move, decide whether the paragraph is right and the other three are wrong, or the other way around. Then fix three of them to match.

Freeze. Put the paragraph under document control. Assign an owner. Set a cadence for coherence review across the four sources. Propagate the frozen version into Section 1 of the technical file, the IFU, the website, the clinical evaluation, and the sales training. From that moment on, the paragraph only changes through document control, and any change automatically triggers a coherence pass on all four sources.

The afternoon this takes is the cheapest afternoon the project buys. Founders who skip it pay for the skip every month until certification.

The Subtract to Ship angle

Subtract to Ship for intended purpose drafting is the same move the rest of the framework makes, applied to a paragraph instead of a process. Every word in the paragraph has to earn its place. If a word does not serve either the medical claim (the tight side) or the honest minimum description of the device, it comes out. If a word constrains the implementation without buying regulatory specificity, it comes out. If a word broadens the scope without being supported by evidence, it comes out. What remains is the narrowest honest statement of what the device is for — and that is the paragraph that survives audit, supports the roadmap, and lets the rest of the file be written once.

The Purpose Pass in the Subtract to Ship framework is the place this discipline lives. Run it on the draft intended purpose before you write anything else in the technical file. Do not skip it, do not defer it, and do not delegate it to someone who does not understand both the regulation and the product roadmap.

Reality Check — Where do you stand?

  1. Can you read your current intended purpose paragraph out loud in thirty seconds, and does every word in it belong to either the medical claim or the honest minimum device description?
  2. If you handed the paragraph to a classification expert who had never seen your product, would they pick the same Annex VIII rule you expect — without asking follow-up questions?
  3. Walking the next twenty-four months of product plans through the paragraph, how many of your planned changes would require rewriting it? If the answer is more than one or two, the paragraph is over-constrained on the implementation axis.
  4. Is every tight-side word — condition, verb, population, user, environment — covered by a clinical evidence plan you can actually afford and execute?
  5. Do the paragraph, the website, the pitch deck, and the draft IFU tell the same story, or is there drift among the four Article 2(12) sources?
  6. Have you ever deliberately removed a medical verb or a broader population from the paragraph because the evidence or the business did not support it?
  7. Is the paragraph under document control with a named owner and a cadence for coherence review, or does it live in a draft somewhere nobody has opened in a month?

Frequently Asked Questions

How specific does the intended purpose have to be under MDR Article 2(12)? Specific enough that Annex VIII classification rules can be applied unambiguously — that means you name the medical condition, the clinical verb from Article 2(1), the patient population, the intended user, and the environment of use. You do not have to name the algorithm, the hardware revision, or specific performance numbers; those belong elsewhere in the technical file.

What counts as over-constraining the intended purpose? Any wording that locks in implementation choices (algorithm, sensor type, hardware version, feature list, exact performance thresholds) or brand language (innovative, AI-powered, next-generation). These do not help classification and they force rewrites every time the engineering team iterates. Cut them and keep them out.

What counts as under-constraining the intended purpose? Missing any of the five tight-side elements: the verb from Article 2(1), the condition, the population, the user, or the environment. A paragraph missing any of these leaves the classification rule ambiguous, and the auditor will default to the more burdensome interpretation.

Can I broaden the intended purpose later if my product grows? Yes, but broadening the intended purpose is treated as a significant change and triggers a change notification to the Notified Body, an update to the classification rationale, an update to the clinical evaluation, and updates to labelling. That is why starting with the narrowest honest paragraph is cheaper than broad-and-later-narrow.

Does the intended purpose need to name the algorithm or model version for a software device? No. The algorithm and the model version belong in the device description and the software lifecycle documentation, not in the intended purpose. Naming them in the paragraph ties the regulatory definition of the device to an implementation choice that will change.

How does the tension between specificity and flexibility actually resolve? By separating the two axes. The tight side — condition, verb, population, user, environment — is specific and stable. The implementation side — algorithm, sensors, features, accuracy numbers, brand language — is kept out of the paragraph entirely and lives in the other sections of the technical file where it can evolve without retriggering change control.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, consolidated text. Articles cited: Article 2(1) definition of medical device; Article 2(12) definition of intended purpose; Article 51 classification; Article 61 clinical evaluation; Annex VIII classification rules. Official Journal L 117, 5.5.2017.

This post is part of the MedTech Startup Strategy & PMF series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The intended purpose paragraph is where market verification becomes legal claim. Write it deliberately, or pay for the carelessness for years.