MDR for Startups: Defining Your Product

If you are building a health or medical app and the letters MDR have started showing up in your inbox, this guide is for you. You do not need any regulatory background. We will build a clear description of your product together, one plain question at a time, using a made-up example app so you can see exactly how it is done. By the end you will have a first draft you can reuse for almost every regulatory step that follows.

Why start with a description?

Everything in the MDR flows from one thing: a clear statement of what your product is and what it is for. The regulation calls this your intended purpose, but you can just think of it as a really good description. Once it is written down, the scarier questions (Is it a medical device? What class is it? What paperwork do I need?) get much easier to answer. So that is where we start.

Meet our example: SkinScan

To keep things concrete, we will use a made-up app called SkinScan. Here is a rough first attempt at describing it, in one sentence:

SkinScan lets someone photograph a mole on their skin and tells them whether it looks like something they should get checked by a doctor.

That is a perfectly good starting point. Now let us sharpen it, one question at a time. Answer each question for your own product as we go.

What does it actually do?

Start with the simplest version of the truth. In one sentence, what does your product do for the person using it? Try not to describe the technology yet, just the job it does. For SkinScan that is the sentence we already have: it looks at a photo of a mole and tells the user whether it might need a doctor's attention.

Who is it for?

Now say who you are building it for. Be specific about the people and, if it matters, their condition. The MDR cares a lot about your target population, because a tool aimed at trained clinicians is judged differently from one aimed at the public. For SkinScan: adults who have noticed a new or changing mole and want a sense of whether it is worth seeing a doctor about.

How does it work?

Next, how does your product achieve what it does? At a high level, is the effect physical or mechanical, chemical or biological, or is software doing the work? You do not need deep detail, just the mechanism. For SkinScan it is software: it analyses the photo with an algorithm that compares the mole against patterns learned from many examples. Nothing physical touches the patient.

Who uses it, and where?

Who actually presses the buttons, and in what setting? A phone app used at home by a member of the public is a very different thing from a tool used by a dermatologist in a clinic, even if they do something similar. For SkinScan: members of the public, at home, on their own phones.

What is it really claiming to do for someone's health?

This is the big one. Look past the features and ask what health-related promise you are making. Are you helping someone spot, track or decide about a health condition? A tool that simply stores photos makes no health claim. SkinScan does: it gives an opinion that could change whether someone seeks care. It does not diagnose anything, but it clearly influences a health decision.

How long, and how often, is it used?

Finally, note how long and how often someone uses it. The regulation calls this the duration of use, split into transient (minutes), short-term (up to 30 days) and long-term (over 30 days). It matters most for devices that are physically in or on the body, but it is a good habit to capture it. For SkinScan: brief, occasional use, whenever someone wants to check a mole.

Do not worry if you cannot answer every question perfectly yet. Your description is a living document, and it will get sharper as your product does. The goal today is a solid first draft, not a finished regulatory file.

Putting it all together

Here is SkinScan's description after answering those questions. Notice how much clearer and more specific it is than the one-liner we started with:

SkinScan is a mobile app for adults who have noticed a new or changing mole. It uses image analysis to assess a photograph of the mole and gives the user an indication of whether it shows features that warrant review by a doctor. It is intended for occasional use at home by members of the public and does not provide a diagnosis.

That single paragraph is now doing real work. Almost every regulatory step from here starts with it.

A finished device description goes further, covering product identifiers, key parts and materials, accessories, versions, and when not to use it. Every one of those sections builds on the paragraph you just wrote, and Health Tech Pathways walks you through them when you get there.

So, is SkinScan a medical device?

Read the description back. Because SkinScan gives an indication that influences whether someone seeks medical care, it has a medical purpose, and that is what makes something a medical device under the MDR. So yes, SkinScan almost certainly is one. To run this test properly on your own product, our step-by-step guide on how to know if your software is a medical device walks through it.

And roughly what class?

Once something is a medical device, the next question is its risk class, which decides how much oversight it needs. Software that gives information used to make a healthcare decision, like SkinScan, usually lands at least in Class IIa under a rule known as Rule 11. You do not need to memorise the rules. When you are ready, these two guides explain the classes in plain terms: our MDR classification guide and, for software specifically, the SaMD classification guide.

What to do with your description now

Keep that paragraph somewhere safe. You will reuse it to:

  • check whether your product is a medical device,
  • work out its class,
  • start your technical documentation,
  • and brief consultants or a notified body without starting from scratch each time.

One good description saves you repeating yourself at every step.

Frequently asked questions

What is an intended purpose?
It is the formal name for a clear statement of what your product is for and who it is for. In practice it is just a really well-written description of your device, and it is the single document almost every regulatory step relies on.
Do I need a perfect description before I start?
No. Treat it as a living document. A solid first draft is enough to get going, and you will refine it as your product matures.
It is very early for us. Is it too soon to think about this?
No, and earlier is cheaper. Writing your description while you are still shaping the product helps you avoid design decisions that make regulation harder and more expensive later.
Does writing a description mean my product is definitely regulated?
Not by itself. The description is the input you use to decide whether your product is a medical device and, if so, what class it falls into. It is the starting point, not the verdict.

This page is a plain-English introduction based on MDR 2017/745, not legal advice. Once you have a description, confirm your qualification and classification with the detailed guides, and with a notified body or competent authority for anything borderline.

Want a shortcut?

The free MDR check asks you these same questions and turns your answers into a clear read on whether you are a medical device and your likely class, with a report you can share with your team.