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

100 lines
3.9 KiB
Markdown
Raw Normal View History

2023-01-26 07:18:07 +00:00
# Intended Use
2023-01-31 21:57:05 +00:00
**Document Change History**
| Version | Date | Author | Change Comment |
|---------|------------|----------------|----------------|
| 0.1 | 2023-02-01 | Markus Thielen | Draft |
2023-01-26 07:18:07 +00:00
## 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.