tech-file/General documents/intended-use.md

# 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: basebox
 * Version: Applies to all versions
 * Basic UDI-DI: Applicable for the medical device which integrates basebox.

## 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.
The following characteristics of an intended use have to be defined by the medical device manufacturer using basebox.

## Intended Medical Indication

N/A. See above.

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