Early access registrations are open for Headstart, a predictable, fixed-price program for becoming compliant.

January 24, 2021

Template: Intended Use (for Medical Devices Under MDD / MDR)

Dr. Oliver Eidel

This is a free template, provided by OpenRegulatory.

A preview of the template is shown below. You can download it as Word (.docx), PDF or markdown file.

The template license applies (don't remove the copyright at the bottom).

Download as:
Beginning of template

Intended Use

Mapping of Requirements to Document Sections

Only relevant if you’re aiming for MDD (and not MDR) compliance:

MDD Class MDD Section Document Section
IIa, IIb, III Annex II, 3.2 c) (All)
I Annex VII, 3 (All)

And vice-versa, only relevant if you’re aiming for MDR (not MDD) compliance:

MDR Class MDR Section Document Section
(All) Annex II, 1.1 a) - d), h), i) (All)

Always relevant:

ISO 14971:2019 Section Document Section
5.2 (All)
IEC 62366-1:2015 Section Document Section
5.1 (All)


Intended Medical Indication

Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by your software.

Patient Population

Describe the patient population your software is intended to be used on. Note that this may overlap with the user profile (section below), but not necessarily. Your software could be used by physicians to diagnose diseases on patients, so in that case, they don’t overlap. Some ideas for characteristics to describe: Age group, weight range, health, condition(s).

Part of the Body / Type of Tissue Interacted With

Should be self-explanatory.

User Profile

Describe the typical user of the software. Some ideas could be: Qualifications, prior training (for your software), technical proficiency, time spent using the software.

Use Environment

Describe the typical use environment. What sort of devices is this running on? Does the software only run on one device or on multiple devices? Is it loud and chaotic like in an emergency ward? How’s the lighting?

Operating Principle

It’s kind of a stretch to describe the “operating principle” of software. I guess this makes more sense for hardware devices. In any case, I’d just generally state what sort of input goes in and what output comes out, e.g. you could be processing images and returning diagnoses.

The device is stand-alone software. It receives input from the user and outputs information.

Variants / Accessories

Describe variants and/or accessories of/to this device, if applicable. For typical stand-alone software of startups, this shouldn’t be applicable.

Template Copyright openregulatory.com. See template license.

Please don’t remove this notice even if you’ve modified contents of this template.

End of template


Regulatory compliance is not rocket science.

But finding a good consultant is.

No Cookie For You Privacy Policy Imprint
No QMS on this planet will save you from creating crappy software.