# Intended Use

**Document Change History**

| Version | Date       | Author         | Change Comment |
|---------|------------|----------------|----------------|
| 0.1     | 2023-02-01 | Markus Thielen | Draft          |


## 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)            |

## Product

 * Name: *\<product name\>*
 * Version: *\<product version\>*
 * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*

## Intended Use

> Describe the core medical functionality of your device and how it treats, diagnoses or alleviates a disease.
> Keep it high-level so that this description is true for as long as possible even when the device is updated.

## Intended Medical Indication

> Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by
> your software. Importantly, also list exclusion criteria: Maybe patients with a certain diagnosis should not
> be using your device.

## Contraindications

> List anything that you want to explicitly exclude from your intended use.

## 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 in patients, so in that case, they don't overlap. Some ideas for characteristics to describe: Age
> group, weight range, health, condition(s).

## 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 Including Software/Hardware

> Describe the typical use environment. What sort of devices is this running on? Does the software only run on
> one device or multiple devices? Is it loud and chaotic like in an emergency ward? How's the lighting?
>
> Also, add other software or hardware which is required by your device. Most commonly, apps require users to
> have a smartphone with a compatible operating system (iOS / Android).

## 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.

## Part of the Body / Type of Tissue Interacted With

The device is stand-alone software. It receives input from the user and outputs information. It doesn't come
in contact with tissue or bodily fluids.

## 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](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).

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