README, intended use

General documents/intended-use.md

@@ -0,0 +1,92 @@
+# 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)            |
+
+## 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.