Repository: OpenSaMD/OpenSaMD (language: python)

Issue:
Pull in rdm



Discussion / hints:

Fix patch:
diff --git a/openregulatory/LICENSE.md b/openregulatory/LICENSE.md
new file mode 100644
index 00000000..f591afe9
--- /dev/null
+++ b/openregulatory/LICENSE.md
@@ -0,0 +1,170 @@
+OpenRegulatory templates are licensed through the Creative Commons Attribution 4.0 International (CC BY 4.0)
+license.
+
+Here's a short, non-legally-binding summary of what that means: You can do whatever you want with them, but
+you must retain the license and copyright notice at the bottom of each template.
+
+Again, and in other words: The copyright notice (this one:
+[templates/copyright-notice.md](templates/copyright-notice.md)) must be shown at the bottom of each template.
+
+The full wording of the license is below.
+
+---
+
+# Creative Commons Attribution 4.0 International
+
+Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
+
+### Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
+
+* __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors).
+
+* __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees).
+
+## Creative Commons Attribution 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
+
+### Section 1 – Definitions.
+
+a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
+
+b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
+
+c. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
+
+d. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
+
+e. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
+
+f. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
+
+g. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
+
+h. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License.
+
+i. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
+
+j. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
+
+k. __You__ means the individual or entity exercising the Licensed Rights under this Public License. __Your__ has a corresponding meaning.
+
+### Section 2 – Scope.
+
+a. ___License grant.___
+
+   1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
+
+       A. reproduce and Share the Licensed Material, in whole or in part; and
+
+       B. produce, reproduce, and Share Adapted Material.
+
+   2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
+
+   3. __Term.__ The term of this Public License is specified in Section 6(a).
+
+   4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
+
+   5. __Downstream recipients.__
+
+       A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
+
+       B. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
+
+   6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
+
+b. ___Other rights.___
+
+   1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
+
+   2. Patent and trademark rights are not licensed under this Public License.
+
+   3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
+
+### Section 3 – License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the following conditions.
+
+a. ___Attribution.___
+
+   1. If You Share the Licensed Material (including in modified form), You must:
+
+       A. retain the following if it is supplied by the Licensor with the Licensed Material:
+
+         i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
+
+         ii. a copyright notice;
+
+         iii. a notice that refers to this Public License;
+
+         iv. a notice that refers to the disclaimer of warranties;
+
+         v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
+
+       B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
+
+       C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
+
+   2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
+
+   3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
+
+   4. If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License.
+
+### Section 4 – Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
+
+a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
+
+b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and
+
+c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
+
+For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
+
+### Section 5 – Disclaimer of Warranties and Limitation of Liability.
+
+a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__
+
+b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__
+
+c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
+
+### Section 6 – Term and Termination.
+
+a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
+
+b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
+
+   1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
+
+   2. upon express reinstatement by the Licensor.
+
+   For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
+
+c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
+
+d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
+
+### Section 7 – Other Terms and Conditions.
+
+a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
+
+b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
+
+### Section 8 – Interpretation.
+
+a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
+
+b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
+
+c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
+
+d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
+
+> Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
+>
+> Creative Commons may be contacted at creativecommons.org
diff --git a/openregulatory/README.md b/openregulatory/README.md
new file mode 100644
index 00000000..00a9548b
--- /dev/null
+++ b/openregulatory/README.md
@@ -0,0 +1,45 @@
+# OpenRegulatory Templates
+
+Templates for ISO 13485, IEC 62304, ISO 14971 and ISO 62366 compliance.
+
+These are markdown files. If you prefer to download them as .docx, .pdf, and .html files, head over to our
+website at [openregulatory.com/templates][openregulatory-templates].
+
+## Rationale
+
+Regulatory compliance is an opaque field, riddled with suboptimal consultants, expensive audits and scarce
+information.
+
+We ([OpenRegulatory][openregulatory]) are trying to change that. We started publishing all [our templates for
+free on our website][openregulatory-templates] which was a huge success! People all over the world suddenly
+had the resources to create regulatory documentation in their garages without paying expensive consultants.
+
+Now, we're moving those templates to this public GitHub repository to improve collaboration. Let's see how it
+works out! :)
+
+## Contributing
+
+Contributions are always welcome!
+
+### Goal and Thoughts on Contributions
+
+Corrections of typos and general housekeeping is always much appreciated!
+
+Adding new content (like new sentences or sections in templates) is also great. But keep in mind: The goal of
+our templates is to be as minimalistic as possible. They should enable startups to pass audits, but not to set
+up the most detailed QMS on this planet. So if your contribution will increase the likelihood of fulfilling
+regulatory requirements and/or passing audits, that's great!
+
+Accordingly, the best possible contribution would be making changes to the templates after having gone through
+an audit with them. That would enable everyone else to look at them and say "wow, those actually passed an
+audit". That would be really cool.
+
+### How do you contribute?
+
+Create a pull request and select me (@olieidel) as reviewer.
+
+
+<!-- Links -->
+
+[openregulatory]: https://openregulatory.com
+[openregulatory-templates]: https://openregulatory.com/templates
diff --git a/openregulatory/templates/clinical_evaluation/clinical-evaluation-plan.md b/openregulatory/templates/clinical_evaluation/clinical-evaluation-plan.md
new file mode 100644
index 00000000..23552e60
--- /dev/null
+++ b/openregulatory/templates/clinical_evaluation/clinical-evaluation-plan.md
@@ -0,0 +1,131 @@
+# Clinical Evaluation Plan
+
+The Clinical Evaluation Plan defines methods for creating and updating the Clinical Evaluation Report. This
+plan is updated later by the post-market clinical follow-up, e.g. to include new search criteria for the
+literature search.
+
+> While the content of the Clinical Evaluation is simple, writing it, coming up with the right structure and
+> forming a sensible line of reasoning (equivalence) can be a bit tricky.
+>
+> These are the guidance documents on Clinical Evaluation. If you're the person writing it, you should read
+> them:
+>
+>  * MDCG 2020-1, 2020-5, 2020-6
+>  * MDCG 2020-13: Quite helpful as it gives you an idea of the structure.
+>  * MEDDEV 2.7.1 rev. 4. (mostly for MDD, but still a good starting point; especially the list of proposed
+>    headings for a report at the end of the document).
+
+## 1. Relevant Documents
+
+ * SOP Clinical Evaluation
+ * Clinical Evaluation Report
+
+## Product
+
+ * Name: *\<product name\>*
+ * Version: *\<product version\>*
+ * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
+
+## Responsibilities
+
+> Describe the roles of people who will be doing the Clinical Evaluation.
+> * Author
+> * Literature search
+> * Evaluation of complaints, customer feedback
+> * Review
+
+## 2. Scope of the Clinical Evaluation
+
+> Note: This section will be copy-pasted into the Clinical Evaluation Report
+
+### 2.1 Device Description
+
+> Copy-paste your Device Description (which includes the Intended Use) here. If it's not done yet, remember to
+> do it later :)
+
+### 2.2 Clinical Benefits, Outcome Parameters
+
+> Describe the clinical benefits you expect from your product. Define how you'll measure those (outcome
+> parameters). You'll probably be planning to do a literature search to prove them - as you know the
+> literature, it makes sense to select outcome parameters which were already established in prior studies.
+
+> Also describe the product claims as stated by MEDDEV 2/7.1 Rev. 4, as stated there:
+> Medical device claims results from general requirements on safety and performance. These claims are part of
+> materials (e. g. IFU, marketing material and other accompanying documents). These product claims will be
+> checked within the clinical evaluation and evidence are made. e.g.
+>
+> * diagnosis for better treatment decision (performance)
+> * xy % accuracy, xy % sensitivity, xy % specificity
+
+### 2.3 Clinical Safety, Methods for Analysis
+
+> Describe your safety parameters, i.e. which things should your product fulfil so that you consider it safe?
+> And your methods, i.e. how will you prove that your product fulfils those safety parameters? A method could
+> be a literature search for past studies, but you could additionally do a Post-Market Clinical Follow-Up to
+> double-check whether that's actually true for your device.
+
+### 2.4 Acceptability of Benefit-Risk Ratio
+
+> After you've defined your benefits and safety parameters, which combination of those is acceptable to you?
+> In the case of most software devices (and apps), you'll probably have subtle benefits (e.g. better disease
+> management, early detection of relapses) while low safety concerns (e.g. disease progression unlikely, not
+> killing anyone).
+
+## 3. Type of Evaluation
+
+> Describe the type of Clinical Evaluation you'll be doing. In 99% of cases as a startup, you'll be claiming
+> equivalence to an already-certified (CE marked) device. You'll have some methodology for searching for such
+> a device. If you need some inspiration, check out the FDA 510k database for FDA-approved devices which claim
+> equivalence to an already-certified device. Those are usually good to compare clinical and technical
+> features and demonstrate equivalence :)
+
+> And based on that, you'll be doing a literature search to come up with adequate clinical data.
+
+## 4. Literature Search
+
+### 4.1 Literature Search Methods
+
+> Describe your literature search methods: The databases you'll be using (PubMed, Google Scholar, Cochrane,
+> Embase), the keywords you'll be entering and how you plan to document it (you'll be creating a table, I
+> suppose).
+
+> I blindly copy-pasted some semi-helpful bullet points from guidance documents here:
+> * The adequacy of search terms: for example, it should be sufficiently broad to establish benchmarks,
+>   determine the general state of the art, determine potential risk, adverse events, undesirable side-effects,
+>   etc.
+> * Note that a search which is restricted to the manufacturer’s own product or the name of their chosen
+>   equivalent could miss important information and therefore is not acceptable.
+> * Databases used (to minimize bias multiple databases should be used).
+> * Acceptability of inclusion and exclusion criteria.
+> * Both favourable and unfavourable data are included.
+> * Strategies for avoiding duplication of data (for example, across different publications or between
+>   the manufacturer and published data).
+> * Literature search and review protocol (i.e. how did the manufacturer test this protocol to ensure
+>   comprehensive identification of relevant data / demonstrate that all relevant data has been retrieved?).
+> * Any deviations from the manufacturer’s literature search protocol.
+> * Overall conclusions regarding the adequacy of search methods, the likelihood of having retrieved all relevant
+>   data, and methods used to avoid bias.
+
+> It makes sense to differentiate between "context" and "pivotal" data:
+> * Context data describes the state of the art (commonly the introduction / literature part of papers)
+> * Pivotal data is used for the appraisal, i.e. that's the data describing the actual study and
+>   outcome(s). In the best case, the pivotal data is about the actual device you're claiming equivalence to.
+
+### 4.2 Literature Appraisal Criteria
+
+> Describe your criteria for clinical data which you deem acceptable for your clinical evaluation. Firstly, the
+> information should be relevant, secondly, you'll probably have some additional hard criteria, like
+> requirements for the study design etc.
+>
+> Also: How will you weigh the information from multiple studies?
+
+> You can evaluate the appraisal of pivotal data by considering the equivalence of the described device
+> literature (e.g. material & methods part, algorithm, models); the level of evidence can be taken from
+> different sources (LoE of American heart association or quality of clinical data according to MDCG Guideline
+> 2020-6).
+
+### 4.3 Additional Databases
+
+> You can also check out additional databases for relevant data and mention how you search them:
+> * Clinical trials: clinicaltrail.gov, DRKS, WHO, ANZCTR
+> * Adverse events: EUDAMED (if it works), FDA MAUDE, FDA Medical Device Recalls
diff --git a/openregulatory/templates/clinical_evaluation/clinical-evaluation-report.md b/openregulatory/templates/clinical_evaluation/clinical-evaluation-report.md
new file mode 100644
index 00000000..17ec673d
--- /dev/null
+++ b/openregulatory/templates/clinical_evaluation/clinical-evaluation-report.md
@@ -0,0 +1,611 @@
+# Clinical Evaluation Report
+
+The Clinical Evaluation Report states the clinical benefits and safety characteristics of the device, based on
+clinical data. It is the output of the Clinical Evaluation Plan.
+
+> While the content of the Clinical Evaluation is simple, writing it, coming up with the right structure and
+> forming a sensible line of reasoning (equivalence) can be a bit tricky.
+>
+> These are the guidance documents on Clinical Evaluation. If you're the person writing it, you should read
+> them:
+>
+>  * MDCG 2020-1, 2020-5, 2020-6
+>  * MDCG 2020-13: Quite helpful as it gives you an idea of the structure.
+>  * MEDDEV 2.7.1 rev. 4. (mostly for MDD, but still a good starting point; especially the list of proposed
+>    headings for a report at the end of the document).
+>
+> Finally, this Clinical Evaluation Report is for Medical Devices. If you are an IVD manufacturer you will
+> write a Performance Evaluation Report which has many similarities but some essential parts are different,
+> e.g., Post-Market Performance Follow-Up and procedural descriptions of evaluation and validation).
+
+## Product
+
+ * Name: *\<product name\>*
+ * Version: *\<product version\>*
+ * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
+
+## Table of Contents
+
+> A list of the sections is presented below. You have to update this manually when you edit headings as this
+> is a markdown file (sorry - guilty dog face).
+
+ 1. List of Abbreviations
+ 2. Product
+ 3. Relevant Documents
+ 4. Scope of the Clinical Evaluation
+ 5. Device
+ 6. Clinical Background, Current Knowledge, State of the Art
+ 7. Type of Evaluation
+ 8. Equivalence
+ 9. Literature Search
+ 10. Clinical Data
+ 11. Post-Market Activities
+ 12. Conclusions
+ 13. Date of the Next Clinical Evaluation
+ 14. Dates and Signatures
+ 15. Qualification of the Responsible Evaluators
+ 16. References
+
+## 1. List of Abbreviations
+
+| Abbreviation | Explanation                                            |
+|--------------|--------------------------------------------------------|
+| AE           | Adverse Event                                          |
+| BfArM        | German Federal Institute for Drugs and Medical Devices |
+| CE           | Communauté Européenne                                  |
+| CER          | Clinical Evaluation Report                             |
+| CI           | Confidence interval                                    |
+| DHF          | Design History File                                    |
+| DMR          | Device Master Record                                   |
+| EUDAMED      | European Database for MEdical Devices                  |
+| FDA          | Food and Drug Administration (US)                      |
+| IFU          | Instruction for Use                                    |
+| LoE          | Level of Evidence                                      |
+| MAUDE        | Manufacturer and User Facility Device Experience       |
+| MEDDEV       | Guideline for Clinical Evaluation of Medical Devices   |
+| MDD          | Medical Device Directive, European Directive 93/42/EEC |
+| MDR          | Medical Device Directive, 2017/745                     |
+| PMS          | Post Market Surveillance                               |
+| PMCF         | Post MArket clinical Follow Up                         |
+| Rev          | Revision                                               |
+| SOP          | Standard Operation Procedure                           |
+| T            | Tendency                                               |
+| C            | Comparability                                          |
+| WHO          | World Health Organization                              |
+
+## 2. Product
+
+ * Name: *\<product name\>*
+ * Version: *\<product version\>*
+ * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
+ * UMDNS-Code:
+ * GMDN-Code:
+
+The classification is based on the following criteria:
+
+> Select one of these two, based on whether you're going for MDD or MDR compliance.
+
+ * Annex IX of the European Directive 93/42/EEC (MDD): *\<if applicable\>*
+ * According to the EU Regulation 2017/745 (MDR) Annex VIII Rules: *\<if applicable\>*.
+
+## 3. Relevant Regulatory References
+
+Other relevant regulatory documents:
+
+* SOP Clinical Evaluation
+* Clinical Evaluation Plan
+* Instructions for Use (IFU)
+
+This clinical evaluation report serves as evidence of conformance with certain General Safety and Performance
+Requirements pursuant to EU Regulation 2017/745 (MDR), Annex I.
+
+Specifically, the following requirements were evaluated as part of this report:
+
+* Chapter 1 (General Requirements), para. 1 and 8
+* Chapter 2.8 (Software Devices), para. 17.2
+
+## 4. Scope of the Clinical Evaluation
+
+> Note: This section is copy-pasted from the Clinical Evaluation Plan.
+
+> The following section can be part of the Clinical Evaluation Plan or pasted here with reference to the
+> respective chapters. Remember that you can update the Clinical Evaluation Plan during your evaluation
+> (e.g., your search criteria are not sufficient).
+>
+> The approach according to the MEDDEV 2.7/1 rev. 4 includes five logical procedural stages in order to
+> evaluate the performance and safety data of the medical device:
+>
+> * Step 0 ("Scope")
+> * Step 1 ("Identification")
+> * Step 2 ("Appraisal")
+> * Step 3 ("Analysis")
+> * Step 4 ("Report")
+
+During the working process, these five steps are iterative and influence each other. The report shows the
+steps in a sequential way. In the present report (step 4), the steps 0 through 3 are corresponding to the
+following chapters:
+
+> List sections of the Clinical Evaluation Report here which cover the steps above.
+
+## 5. Device
+
+### 5.1 Device Description
+
+> Copy-paste your Device Description (which includes the Intended Use) here. If it's not done yet, remember to
+> do it later :)
+
+> Also, reference your Essential Requirements Document here.
+
+### 5.2 Clinical Benefits, Outcome Parameters
+
+> Medical device claims are statements from accompanying documents, marketing material, your website,
+> etc. that include information about the performance and safety of the medical device (information by the
+> manufacturer). The clinical evaluation is done in order to determine whether those claims are confirmed by
+> sufficient clinical evidence.
+>
+> So, if your website claims that your device cures back pain in 50% of patients after 14 days, here's the
+> place to list that claim and show explain how you'll prove it.
+
+Claims that have not been stated so far (e.g., in the IFU) are described below and sorted according to their
+meaning for performance and safety. In this clinical evaluation, it was determined that the claims are
+sufficiently supported by clinical data.
+
+Performance-related product claims:
+
+ * Claim 1
+ * Claim 2
+
+### 5.3 Clinical Safety, Methods for Analysis
+
+> Describe your safety parameters, i.e., which things should your product fulfil so that you consider it safe?
+> And your methods, i.e., how will you prove that your product fulfils those safety parameters? A method could
+> be a literature search for past studies, but you could additionally do a Post-Market Clinical Follow-Up to
+> double-check whether that's actually true for your device.
+
+Safety-related product claims:
+
+ * Claim 1
+ * Claim 2
+
+### 5.4 Acceptability of Benefit-Risk-Ratio
+
+> After you've defined your benefits and safety parameters, which combination of those is acceptable to you?
+> In the case of most software devices (and apps), you'll probably have subtle benefits (e.g., better disease
+> management, early detection of relapses) while low safety concerns (e.g., disease progression unlikely, not
+> killing anyone).
+
+## 6. Clinical Background, Current Knowledge, State of the Art
+
+> This chapter focus on literature  and guidelines that describe the current state of the art and
+> other topics. It is similar to the literature / introduction chapter of papers.
+>
+> It makes sense to differentiate between "context" and "pivotal" data:
+> * Context data describes the state of the art (commonly the introduction / literature part of papers)
+> * Pivotal data is used for the appraisal, i.e., that's the data describing the actual study and
+>   outcome(s). In the best case, the pivotal data is about the actual device you're claiming equivalence to.
+
+### 6.1 Clinical Background & Current Knowledge
+
+> Describe the clinical context of the disease you're treating: How are patients currently treated? Which
+> symptoms do they have, which diagnostic modalities are being used to establish a diagnosis, which treatment
+> options exist? What are the benefits and drawbacks of current treatment options?
+
+### 6.2 State of the Art incl. Alternative Treatments
+
+> Given the current treatment options, what is the preferred, "state of the art" treatment? What are its
+> benefits and drawbacks? Are there recent scientific achievements (studies, new technologies, software) which
+> may be promising to improve this state-of-the-art treatment? Also, what are alternative treatments?
+
+## 7. Type of Evaluation
+
+> Note: This section is copy-pasted from the Clinical Evaluation Plan.
+
+## 8. Literature Search
+
+### 8.1 Literature Search Methods
+
+> Copy-paste from Clinical Evaluation Plan.
+
+### 8.2 Literature Appraisal Criteria
+
+> Copy-paste from Clinical Evaluation Plan.
+
+> You can describe it as a flow chart, e.g.:
+>
+> 1. Initial search with all publications from the relevant databases.
+> 2.1 Potentially relevant papers (from the first skimming of article titles / abstracts)
+> 2.2 Irrelevant papers
+> 3. Potentially relevant papers found in irrelevant papers
+> 4.1 Relevant paper used for context
+> 4.2 Relevant paper used for a single appraisal (pivotal data)
+
+### 8.3 Literature Search Protocol
+
+> A table which lists your actual literature search results. For each entry, you should decide whether it's
+> acceptable (based on your appraisal criteria) or not. I pre-wrote some tables to give you an idea of the
+> structure below. You could separate the tables based on the database where you did the search (PubMed,
+> Google Scholar).
+>
+> It could make sense to put this in a separate document (rather: a spreadsheet).
+>
+> Here are some bullet points from the guidance:
+> * Literature search protocol provided
+> * Literature search reports provided
+> * Full list of retrieved articles provided
+> * Full list of excluded articles provided, with reasons for exclusion Full text copies of relevant documents
+>   available
+
+### 8.4 Database Search Overview
+
+| Database | Search term | # Hits | # Evaluated Abstracts | # Potential Relevant Publications |
+|----------|-------------|--------|-----------------------|-----------------------------------|
+|          |             |        |                       |                                   |
+
+### 8.5 Database: PubMed
+
+| Title | Author | Year | Summary | Relevant? Why?                          |
+|-------|--------|------|---------|-----------------------------------------|
+|       |        |      |         | *e.g., similar design, similar features* |
+
+### 8.6 Database: Google Scholar
+
+| Title | Author | Year | Summary | Relevant? Why? |
+|-------|--------|------|---------|----------------|
+|       |        |      |         |                |
+
+### 8.7 Database: Cochrane
+
+| Title | Author | Year | Summary | Relevant? Why? |
+|-------|--------|------|---------|----------------|
+|       |        |      |         |                |
+
+### 9.8 Literature Search Report
+
+> Briefly summarize how many studies you reviewed, how many you deemed acceptable and why you didn't include
+> the unacceptable ones (probably because they didn't conform to the appraisal criteria).
+
+> Describe a gap analysis which information could not be found during your search e.g., specific
+> functionalities of your device, limited number of clinical data in publications.
+
+### 8.10 Evaluation of study Quality
+
+#### 8.10.1  Level of Evidence (LoE)
+
+> Take a sufficient classification to evaluate the quality of your study. You can use the LoE from MDCG 2020-6
+> or from the American Heart Association.
+
+#### 8.10.2 Tendency (T)
+
+> The MEDDEV 2.7/1 rev. 4 requires that literature is used that confirms as well as questions the suitability
+> of the evaluated medical device.
+>
+>  * Positive: + (Confirms clinical suitability)
+>  * Negative: - (Does not confirm clinical suitability)
+>  * Indifferent: i (No statement to the clinical suitability possible)
+
+### 8.10.3 Comparability (C)
+
+> For the consideration of the relevance of literature data for the clinical evaluation it is necessary to make
+> a statement about the comparability to the medical device to be evaluated. This statement about the
+> comparability is made according to the described criteria from chapter "Equivalence" above.
+
+### 8.10.4  Single Appraisal of Searched Clinical Studies
+
+> This chapter is highly important for medical device evaluation. Here you take all the publications from
+> the literature search and evaluate them to prove equivalence with your device and prove the respective
+> product claims. The latter can also be proven by other activities (e.g., PMS, equivalent device, usability
+> testing, result of adverse events etc.).
+
+### 8.10.5 Literature Data on the Performance of the Medical Device
+
+> Focus here on equivalent devices that support your performance claims.
+
+> Do the paper description in the same way e.g.:
+>
+>  * First, describe the study with its main characteristics regarding the quality and relevance are made.
+>    (Study design, patient number, mean age inclusion and exclusion criteria, used product, endpoint,
+>    results of performance, conclusion of the author).
+>  * Complications, side-effects, adverse events.
+>  * A consideration of the study according to the criteria. (LoE, T, C)
+
+In the following, the selected literature references, which were categorized as "relevant" (appraisal), are
+evaluated. This was done according to the following scheme:
+
+#### 8.10.6 Literature Data about the Safety of the Medical Device
+
+> Focus here on equivalent devices that support your Safety claims. So you do not need to describe the LoE
+> since potential risks can also arise from case studies (which might have a low LoE).
+
+## 9. Clinical Data
+
+### 9.1 Clinical Data From Literature
+
+> List all the clinical data you got from studies which matched your appraisal criteria.
+
+### 9.2 Clinical Data from Clinical Study Databases
+
+> List all the clinical data you got from studies (clinical trials.gov, ANCTR, DRKS, WHO etc.).
+
+### 9.3 Clinical Data From Adverse Event Databases
+
+> List all the clinical data you got from studies which matched your appraisal criteria (BfArM, MAUDE, FDA
+> Medical Device Recall, EUDAMED (when applicable)).
+
+### 9.4 Summary and Appraisal of Clinical Data
+
+> Summarize all the clinical data from above :)
+
+### 9.5 Analysis of the Clinical Data
+
+> Analyze the clinical data with a focus on whether your targets of clinical benefits and safety were
+> fulfilled.
+
+## 10. Equivalence
+
+> NOTE: first of all, under the European MDR, equivalence data is not as significant anymore as it used to be
+> under the MDD. That's because the MDR now actually requires you to have access to the clinical data that you
+> are referencing to support your own device's safety and performance. Access to the data of competitor
+> devices is usually rather tricky though. That's why we're using equivalence in our template only as a
+> another indicator on the side.
+>
+> It's important though to understand why you're conducting this equivalent device comparison: you want to
+> show that another device is very safe and has a reliable performance. You then refer to those datapoints
+> and, after demonstrating that your device is equivalent to the other, argue that those datapoints also
+> support your device profile. That means:
+>
+> * Make sure to include search terms for the equivalent device(s), such as the brand name, in your literature
+>   search (para. 8)
+> * Make sure to include search terms for the equivalent device(s), such as the brand name, in your literature
+>   search (para. 9)
+>
+> You don't really analyze the resulting information in the above paragraphs, but draw your main conclusion
+> from this below in para. 10.2.4.
+
+### 10.1 Equivalent Device
+
+> Describe the equivalent device you're comparing yourself to, mainly its Intended Use.
+
+### 10.2 Demonstration of Equivalence (Technical, Biological, Clinical)
+
+> Here you have to demonstrate that your device is equivalent to the Equivalent Device. You accomplish that by
+> creating a table in which you list certain characteristics, and describe those characteristics both for the
+> Equivalent Device and for your device. The idea is that your device is mostly the same in most
+> characteristics.
+
+> The tables are split into general stuff (first table), then Clinical, Technical and Biological equivalence
+> as per the guidance documents. I pre-filled some of the table rows for you as they should be universal,
+> e.g., Intended Use, Medical Indication(s) and Programming Language. But definitely feel free to add
+> additional rows which are useful for comparing your device to the equivalent one. Maybe you're using
+> recurrent neural networks and the equivalent device is, too? Then add that.
+
+|                        | Equivalent Device    | This Device          |
+|------------------------|----------------------|----------------------|
+| Intended Use           |                      |                      |
+| Medical Indication(s)  |                      |                      |
+| Device Classification  |                      |                      |
+| Principle of Operation | Stand-alone Software | Stand-alone Software |
+
+According to standard methodology, the level of similarity or equivalence of a comparable medical device to
+the evaluated medical device is divided into the three categories "clinical", "technical" and "biological".
+
+Within each category there are four steps for the evaluation of the equivalence level:
+
+| Equivalence Level       | Score |
+|-------------------------|-------|
+| Very Equivalent         | 3     |
+| Nearly Equivalent       | 2     |
+| In some aspects similar | 1     |
+| In some aspects similar | 0     |
+
+After a score has been assigned to all three categories (clinical, technical, biological), those scores are
+summed up. The total equivalence is determined based on the sum of those values:
+
+| Sum | Equivalence             |
+|-----|-------------------------|
+| 8-9 | Very Equivalent         |
+| 6-7 | Nearly Equivalent       |
+| 3-5 | In some aspects similar |
+| 0-2 | Very different          |
+
+> For software devices, adjust the score correspondingly. For example, you could say:
+> "As the biological category typically does not apply for software devices, the total equivalence is
+> determined based on the sum of those values as follows" and use an adjusted score: 6 // 5 // 3-4 // 0-2.
+
+
+#### Clinical Equivalence
+
+The device is considered clinically equivalent if it is:
+
+ * Used for the same clinical condition
+ * Used for the same intended use
+ * Used at the same site in the body
+ * Used in a similar population
+ * Not foreseen to deliver significantly different performances
+ * Similar performances such as the expected clinical effect, the specific intended purpose, the duration of
+   use, etc.
+
+#### Technical Equivalence
+
+The device is considered technically equivalent if it:
+
+ * Is of a similar design
+ * Is used under the same conditions of use
+ * Has a similar specifications and properties
+ * Has a similar intensity of energy, tensile strength, viscosity, surface characteristics, wavelength
+ * Has a similar surface texture, porosity, particle size, nanotechnology, specific mass, atomic inclusions
+ * Uses a similar deployment methods
+ * Has similar principles of operation and critical performance requirements
+
+#### Biological Equivalence
+
+> For stand-alone software:
+
+Not applicable. The device doesn't come in contact with human tissue or body fluids.
+
+> For medical devices which are a part of a hardware medical device:
+>
+> Note: Medical device monitors are also medical devices according to 60601-1.
+
+The device is considered biologically equivalent if it:
+
+ * Is similar or has similar effecting materials which are in contact with body tissue and fluids
+
+#### Optional: Effectiveness Equivalence
+
+The device is considered to have equivalent effectiveness, if it:
+
+ * Has similar Sensitivity, Specificity, Accuracy, NNP, PPV, etc.
+
+#### 10.2.1 Clinical Equivalence
+
+> Note: The MDR doesn't explicitly state that the device needs to be used for the same medical indication,
+> gender and duration of use. But it should be used for the same clinical condition or purpose including
+> similar severity and stage of the disease.
+
+|                                      | Equivalent Device | This Device |
+|--------------------------------------|-------------------|-------------|
+| Clinical Condition                   |                   |             |
+| Disease Stage                        |                   |             |
+| Site in Body                         |                   |             |
+| Population: Age, Anatomy, Physiology |                   |             |
+| Clinical Effect                      |                   |             |
+| Duration of Use                      |                   |             |
+| Significant Performance Difference   |                   |             |
+
+**Clinical Equivalence Score: \<enter number between 0 and 3\>**
+
+#### 10.2.2 Technical Equivalence
+
+|                                | Equivalent Device | This Device |
+|--------------------------------|-------------------|-------------|
+| Software Algorithm             |                   |             |
+| Programming Language           |                   |             |
+| Graphical User Interface (GUI) |                   |             |
+| Web-based Application          |                   |             |
+| Inputs                         |                   |             |
+| Outputs                        |                   |             |
+
+> The following table can be added if it is a hardware-related Medical Device:
+
+|                                         | Equivalent Device | This Device |
+|-----------------------------------------|-------------------|-------------|
+| Design                                  |                   |             |
+| Dimension                               |                   |             |
+| Operating Condition                     |                   |             |
+| Physical Characteristics (e.g., weight) |                   |             |
+| Data transmission                       |                   |             |
+
+**Technical Equivalence Score: \<enter number between 0 and 3\>**
+
+#### 10.2.3 Biological Equivalence
+
+> For stand-alone software:
+
+Not applicable. The device doesn't come in contact with human tissue or body fluids.
+
+> For medical devices which are a part of a hardware medical device:
+
+|                                                          | Equivalent Device | This Device |
+|----------------------------------------------------------|-------------------|-------------|
+| Material/ Radiation in Contact With Body (User/ Patient) |                   |             |
+
+**Biological Equivalence Score: \<enter number between 0 and 3\>**
+
+#### 10.2.4 Conclusion
+
+> Describe your conclusion based on the sum of the numbers values that you gave for each aspect of your
+> equivalence evaluation.
+>
+> It would be also good to describe, on a high level, the outcome of your evaluation from the following
+> processes:
+>
+> * Risk Management
+> * Biocompatibility investigation (if applicable)
+> * Performance Testing
+> * Usability Testing (formative / summative evaluation)
+> * Post-Market Surveillance/ Post-Market Clinical Follow-up
+
+**Total Equivalence Score: \<enter number between 0 and 9\>**
+
+## 11. Post-Market Activities
+
+> This chapter is used to summarize your PMS/ PMCF activities. During the clinical evaluation you evaluate
+> the information of your safety and performance claims as well as general requirements on safety &
+> performance. If you can not cover certain aspects you might need to add them to your PMS/ PMCF - Plan.
+
+> Summarize your post-market activities. You can copy-paste a lot of those here. At the minimum, you'll have a
+> Post-Market Surveillance Plan and Report. If this is your initial certification, your report may be empty as
+> you haven't brought your device to market yet.
+
+> Additionally, you may have a Post-Market Clinical Follow-Up (PMCF) Plan and Report which essentially has the
+> content of "we'll be tracking some data to make sure that our claims of clinical benefits and safety are
+> actually true".
+
+> Here's what the guidance states about it:
+> Describe how the manufacturer will verify the presumption that there would be no clinically significant
+> difference in the safety and clinical performance of the device under evaluation compared with the
+> equivalent device by post market surveillance or post market clinical follow-up?
+
+> * PMS Plan
+> * PMS Report
+> * PMCF Plan
+> * PMCF Report
+> * PSUR (if relevant)
+
+## 12. Conclusions
+
+> Your conclusion is whether the clinical data shows that your goals (benefit/ performance and safety) are
+> fulfilled. Reference your claims you stated before.
+
+## 13. Date of the Next Clinical Evaluation
+
+> When will you be doing the next clinical evaluation and updating this report?
+
+## 14. Dates and Signatures
+
+> Date and sign the report. If your document management system supports it, you can digitally sign by typing
+> e.g., your initials in the "Signature" field. Otherwise, you can still sign it the old-school way (print it
+> and sign the sheet of paper, ugh).
+
+| Activity | Name | Signature |
+|----------|------|-----------|
+| Creation |      |           |
+| Review   |      |           |
+| Approval |      |           |
+
+## 15. Qualification of the Responsible Evaluators
+
+> Attach CVs of the people who were involved in writing the Clinical Evaluation. They must fulfil some
+> criteria (it's complicated), so I'll just copy-paste MEDDEV 2.7.1 rev. 4 here:
+
+> * The manufacturer defines requirements for the evaluators that are in line with the nature of the device
+>    under evaluation and its clinical performance and risks.
+>  * The manufacturer should be able to justify the choice of the evaluators through reference to their
+>    qualifications and documented experience, and present a declaration of interest for each evaluator.
+>
+> As a general principle, the evaluators should possess knowledge of the following:
+>  * research methodology (including clinical investigation design and biostatistics); MEDDEV 2.7/1 revision 4
+>    page 14 of 65
+>  * information management (e.g., scientific background or librarianship qualification; experience with relevant
+>    databases such as Embase and Medline);
+>  * regulatory requirements; and
+>  * medical writing (e.g., post-graduate experience in a relevant science or in medicine; training and
+>    experience in medical writing, systematic review and clinical data appraisal).
+>
+> With respect to the particular device under evaluation, the evaluators should in addition have knowledge of:
+>  * the device technology and its application;
+>  * diagnosis and management of the conditions intended to be diagnosed or managed by the device, knowledge of
+>    medical alternatives, treatment standards and technology (e.g., specialist clinical expertise in the
+>    relevant medical speciality).
+>
+> The evaluators should have at least the following training and experience in the relevant field:
+>  * a degree from higher education in the respective field and 5 years of documented professional experience;
+>    or
+>  * 10 years of documented professional experience if a degree is not a prerequisite for a given task.
+>
+> There may be circumstances where the level of evaluator expertise may be less or different; this should be
+> documented and duly justified.
+
+## 16. References
+
+> Papers and other references which you cite go here.
diff --git a/openregulatory/templates/clinical_evaluation/sop-clinical-evaluation.md b/openregulatory/templates/clinical_evaluation/sop-clinical-evaluation.md
new file mode 100644
index 00000000..e61cd716
--- /dev/null
+++ b/openregulatory/templates/clinical_evaluation/sop-clinical-evaluation.md
@@ -0,0 +1,91 @@
+| Regulatory Requirement | Document Section |
+|------------------------|------------------|
+| MDD Annex I and X      | All              |
+| MDR Annex XIV          | All              |
+| MEDDEV 2.7/1, rev. 4   | All              |
+
+## Summary
+
+This SOP describes the development of medical devices in accordance with regulatory requirements of Annex I
+and X (MDD) and Annex XIV (MDR) regarding medical device clinical performance. It ensures the level of
+demonstrated safety and risk-benefit ratio that is required for our medical devices both for initial
+certification and for continued safe use in the market.
+
+## Process Steps
+
+### 1.1 Clinical Evaluation Plan
+
+The clinical evaluation is initiated following a Management decision to place a new or updated medical device
+on the market. The organization follows this process both for initial market placement and for continuous
+updates during the marketing phase.
+
+The initial clinical evaluation is planned as part of the Clinical Evaluation Plan. During the marketing
+phase, this plan is continuously updated as part of the Post-Market Clinical Follow-Up.
+
+External partners can be involved in both conducting the initial clinical evaluation and the post-market
+clinical follow-up in order to ensure higher clinical expertise during the process and lower the risk of
+regulatory nonconformity. In this case, different external partners should be evaluated with regard to
+sufficient experience (see MEDDEV 2.7/1 rev. 4 section 6.2). The Head of the Medical Team serves as the point
+of contact to provide all relevant information to the partner.
+
+> NOTE: if your organization maintains a purchasing process, the selection of an external partner for the
+> clinical evaluation should be subject to supplier evaluation.
+
+|              |                                                                                                                                                                                  |
+|--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Participants | Medical Team                                                                                                                                                                     |
+| Input        | Initial release: decision on new device, preliminary product specifications (intended use, risk assessment, available preclinical data, information on equivalent devices, etc.) |
+| Output       | Initial release: completed Clinical Evaluation Plan                                                                                                                              |
+
+
+### 1.2 Clinical Evaluation Report
+
+Relevant data is collected and analyzed as part of writing the Clinical Evaluation Report to evaluate the
+device’s clinical performance.  At minimum, the clinical evaluation must take account of:
+
+* Intended use (incl. user and patient population, use environment, device features)
+* Data to support equivalence with other devices (if applicable)
+* Discussion of state of the art technology
+* Discussion of the selected categories of clinical data, the quality of clinical data and its sufficiency to
+  support an overall balanced risk-benefit ratio of the device and compliance with the General Safety
+  Performance Requirements (MDR) / Essential Requirements (MDD).
+
+In the course of data collection and analysis, new risks may be identified and are documented accordingly as
+updates to the risk management file.
+
+> NOTE: where a Notified Body is involved in the conformity assessment of the device and the Medical team
+> identifies remaining uncertainty with regard to the sufficiency of the clinical data, the Notified Body can
+> be contacted to discuss additional measures (e.g., as part of the post-market clinical follow-up) that ensure
+> product conformity and approval.
+
+|              |                                                                         |
+|--------------|-------------------------------------------------------------------------|
+| Participants | Medical Team                                                            |
+| Input        | Product specifications                                                  |
+| Output       | Completed Clinical Evaluation Report<br>If necessary: updated risk file |
+
+### 1.3 Post-Market Clinical Follow-Up (PMCF)
+
+Following the initial clinical evaluation, the organization plans the post-market clinical follow-up for the
+medical device, ensuring its continuous safety and sufficient performance during the marketing phase. The PMCF
+serves as input to regularly update the clinical evaluation.
+
+The Medical team is responsible to compile and implement a Post-Marketing Clinical Follow-Up Plan, including
+at minimum:
+
+* Methodology for data collection and justification for selected methods
+* Consideration of new data related to the risk management file, the claims discussed in the Clinical
+  Evaluation Report or applicable regulations
+* Specification of the PMCFP period (no longer than one year), including a time plan for PMCF activities and
+  the next update of the clinical evaluation
+
+The CAPA process must be initiated if new information collected as part of the PMCF activities indicates that
+a balanced risk-benefit ratio and the safety of the device is in question.
+
+All PMCF activities conducted per PMCF period are documented in a Post-Market Clinical Follow-Up Report.
+
+|              |                                                                                                                              |
+|--------------|------------------------------------------------------------------------------------------------------------------------------|
+| Participants | Medical team                                                                                                                 |
+| Input        | Clinical Evaluation Report New clinical data during the marketing phase                                                          |
+| Output       | Completed Post-Market Clinical Follow-Up Plan and Report<br>If necessary: PMCF measures (e.g., CAPA, updated risk file, etc.) |
diff --git a/openregulatory/templates/copyright-notice.md b/openregulatory/templates/copyright-notice.md
new file mode 100644
index 00000000..5b566208
--- /dev/null
+++ b/openregulatory/templates/copyright-notice.md
@@ -0,0 +1,6 @@
+---
+
+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.
diff --git a/openregulatory/templates/data_protection/data-protection-statement-website.md b/openregulatory/templates/data_protection/data-protection-statement-website.md
new file mode 100644
index 00000000..375ffddd
--- /dev/null
+++ b/openregulatory/templates/data_protection/data-protection-statement-website.md
@@ -0,0 +1,366 @@
+> Disclaimer: this privacy statement refers to websites in the following context:
+>
+> * Your website does not typically require visitors to enter personal data in order to user its services.
+> * No particular "legitimate interests" (section 10)
+> * No automated decision-making (section 14)
+> * Particular website features: newsletter incl. tracking (if, for example, your website uses Google
+>   Analytics, you should consider a separate sub-section for this)
+>
+> It's painful - but you will have to go through the entire text and adjust it to your own company website
+> where necessary. We hope this template still hopes you with a general structure.
+
+# Website Data Protection Statement for Data Subjects Pursuant to Articles 13 and 14 of the EU General Data Protection Regulation
+
+Data protection is a particularly high priority for the management of \<enter company name\>. The use of the
+website of \<enter company name\> is possible without any indication of personal data; however, if a data
+subject wants to use special enterprise services via our website, processing of personal data could become
+necessary. If the processing of personal data is necessary and there is no statutory basis for such
+processing, we generally obtain consent from the data subject.
+
+The processing of personal data, such as the name, address, e-mail address, or telephone number of a data
+subject shall always be in line with the General Data Protection Regulation (GDPR), and in accordance with the
+country-specific data protection regulations applicable to \<enter company name\>. By means of this data
+protection declaration, our company would like to inform the general public of the nature, scope, and purpose
+of the personal data we collect, use and process. Furthermore, data subjects are informed, by means of this
+data protection declaration, of the rights to which they are entitled.
+
+As the controller, \<enter company name\> has implemented technical and organizational measures to ensure the
+most complete protection of personal data processed through this website. However, internet-based data
+transmissions may in principle have security gaps, so absolute protection may not be guaranteed. For this
+reason, every data subject is free to transfer personal data via alternative means, e.g. by telephone.
+
+## 1. Definitions
+
+The data protection declaration of \<enter company name\> is based on the terms used by the European
+legislator for the adoption of the General Data Protection Regulation (GDPR). Our data protection declaration
+should be legible and understandable for the general public, as well as our customers and business
+partners. To ensure this, we would like to first explain the terminology used.
+
+In this data protection declaration, we use, inter alia, the following terms:
+
+* **a) Personal data** Personal data means any information relating to an identified or identifiable natural
+  person (“data subject”). An identifiable natural person is one who can be identified, directly or
+  indirectly, in particular by reference to an identifier such as a name, an identification number, location
+  data, an online identifier or to one or more factors specific to the physical, physiological, genetic,
+  mental, economic, cultural or social identity of that natural person.
+* **b) Data subject** Data subject is any identified or identifiable natural person, whose personal data is
+  processed by the controller responsible for the processing.
+* **c) Processing** Processing is any operation or set of operations which is performed on personal data or on
+  sets of personal data, whether or not by automated means, such as collection, recording, organisation,
+  structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission,
+  dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
+* **d) Restriction of processing** Restriction of processing is the marking of stored personal data with the
+  aim of limiting their processing in the future.
+* e) Profiling Profiling means any form of automated processing of personal data consisting of the use of
+  personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or
+  predict aspects concerning that natural person's performance at work, economic situation, health, personal
+  preferences, interests, reliability, behavior, location or movements.
+* **f) Pseudonymization** Pseudonymization is the processing of personal data in such a manner that the
+  personal data can no longer be attributed to a specific data subject without the use of additional
+  information, provided that such additional information is kept separately and is subject to technical and
+  organizational measures to ensure that the personal data are not attributed to an identified or identifiable
+  natural person.
+* **g) Controller or controller responsible for the processing** Controller or controller responsible for the
+  processing is the natural or legal person, public authority, agency or other body which, alone or jointly
+  with others, determines the purposes and means of the processing of personal data; where the purposes and
+  means of such processing are determined by Union or Member State law, the controller or the specific
+  criteria for its nomination may be provided for by Union or Member State law.
+* **h) Processor** Processor is a natural or legal person, public authority, agency or other body which
+  processes personal data on behalf of the controller.
+* **i) Recipient** Recipient is a natural or legal person, public authority, agency or another body, to which
+  the personal data are disclosed, whether a third party or not. However, public authorities which may receive
+  personal data in the framework of a particular inquiry in accordance with Union or Member State law shall
+  not be regarded as recipients; the processing of those data by those public authorities shall be in
+  compliance with the applicable data protection rules according to the purposes of the processing.
+* **j) Third party** Third party is a natural or legal person, public authority, agency or body other than the
+  data subject, controller, processor and persons who, under the direct authority of the controller or
+  processor, are authorized to process personal data.
+* **k) Consent** Consent of the data subject is any freely given, specific, informed and unambiguous
+  indication of the wishes by which he or she, by a statement or by a clear affirmative action, signifies
+  agreement to the processing of personal data relating to him or her.
+
+## 2. Name and Address of the controller
+
+Controller for the purposes of the General Data Protection Regulation (GDPR), other data protection laws
+applicable in Member states of the European Union and other provisions related to data protection is:
+
+\<enter company name, address and contact details\>
+
+## 3. Collection of general data and information
+
+The website of \<enter company name\> collects a series of general data and information when a data subject or
+automated system calls up the website. This general data and information are stored in the server log
+files. Collected may be (1) the browser types and versions used, (2) the operating system used by the
+accessing system, (3) the website from which an accessing system reaches our website (so-called referrers),
+(4) the sub-websites, (5) the date and time of access to the Internet site, (6) an Internet protocol address
+(IP address), (7) the Internet service provider of the accessing system, and (8) any other similar data and
+information that may be used in the event of attacks on our information technology systems.
+
+When using this general data and information, \<enter company name\> does not draw any conclusions about the
+data subject. Rather, this information is needed to (1) deliver the content of our website correctly, (2)
+optimize the content of our website as well as its advertisement, (3) ensure the long-term viability of our
+information technology systems and website technology, and (4) provide law enforcement authorities with the
+information necessary for criminal prosecution in case of a cyber-attack. Therefore, \<enter company name\>
+analyzes anonymously collected data and information statistically, with the aim of increasing the data
+protection and data security of our company, and to ensure an optimal level of protection for the personal
+data we process. The anonymous data of the server log files are stored separately from all personal data
+provided by a data subject.
+
+## 4. Subscription to our newsletters
+
+On the website, users are given the opportunity to subscribe to our enterprise's newsletter. The input mask
+used for this purpose determines what personal data are transmitted, as well as when the newsletter is ordered
+from the controller.
+
+\<enter company name\> informs its customers and business partners regularly by the means of a newsletter
+about company offers. The enterprise's newsletter may only be received by the data subject if (1) the data
+subject has a valid e-mail address and (2) the data subject registers for the newsletter shipping. A
+confirmation e-mail will be sent to the e-mail address registered by a data subject for the first time for
+newsletter shipping, for legal reasons, in the double opt-in procedure. This confirmation e-mail is used to
+prove whether the owner of the e-mail address as the data subject is authorized to receive the newsletter.
+
+During the registration for the newsletter, we also store the IP address of the computer system assigned by
+the Internet service provider (ISP) and used by the data subject at the time of the registration, as well as
+the date and time of the registration. The collection of this data is necessary in order to understand the
+(possible) misuse of the e-mail address of a data subject at a later date, and it therefore serves the aim of
+the legal protection of the controller.
+
+The personal data collected as part of a registration for the newsletter will only be used to send our
+newsletter. In addition, subscribers to the newsletter may be informed by e-mail, as long as this is necessary
+for the operation of the newsletter service or a registration in question, as this could be the case in the
+event of modifications to the newsletter offer, or in the event of a change in technical circumstances. There
+will be no transfer of personal data collected by the newsletter service to third parties. The subscription to
+our newsletter may be terminated by the data subject at any time. The consent to the storage of personal data,
+which the data subject has given for shipping the newsletter, may be revoked at any time. For the purpose of
+revocation of consent, a corresponding link is found in each newsletter. It is also possible to unsubscribe
+from the newsletter at any time directly on the website of the controller, or to communicate this to the
+controller in a different way.
+
+## 5. Newsletter-Tracking
+
+Our newsletter contains so-called tracking pixels. A tracking pixel is a miniature graphic embedded in such
+e-mails, which are sent in HTML format to enable log file recording and analysis. This allows a statistical
+analysis of the success or failure of online marketing campaigns. Based on the embedded tracking pixel,
+\<enter company name\> may see if and when an e-mail was opened by a data subject, and which links in the
+e-mail were called up by data subjects.
+
+Such personal data collected in the tracking pixels contained in the newsletters are stored and analyzed by
+the controller in order to optimize the shipping of the newsletter, as well as to adapt the content of future
+newsletters even better to the interests of the data subject. These personal data will not be passed on to
+third parties. Data subjects are at any time entitled to revoke the respective separate declaration of consent
+issued by means of the double-opt-in procedure. After a revocation, these personal data will be deleted by the
+controller. \<enter company name\> automatically regards a withdrawal from the receipt of the newsletter as a
+revocation.
+
+## 6. Routine erasure and blocking of personal data
+
+The data controller shall process and store the personal data of the data subject only for the period
+necessary to achieve the purpose of storage, or as far as this is granted by the European legislator or other
+legislators in laws or regulations to which the controller is subject to. If the storage purpose is no longer
+applicable, or if a storage period prescribed by the European legislator or another competent legislator
+expires, the personal data are routinely blocked or erased in accordance with legal requirements.
+
+## 7. Rights of the data subject
+
+* **a) Right of confirmation (Art. 15 GDPR)** Each data subject shall have the right granted by the European
+  legislator to obtain from the controller the confirmation as to whether or not personal data concerning him
+  or her are being processed. If a data subject wishes to avail himself of this right of confirmation, he or
+  she may, at any time, contact any employee of the controller.
+* **b) Right of access (Art. 15 GDPR)** Each data subject shall have the right granted by the European
+  legislator to obtain from the controller free information about his or her personal data stored at any time
+  and a copy of this information. Furthermore, the European directives and regulations grant the data subject
+  access to the following information:
+  * the purposes of the processing;
+  * the categories of personal data concerned;
+  * the recipients or categories of recipients to whom the personal data have been or will be disclosed, in
+    particular recipients in third countries or international organisations;
+  * where possible, the envisaged period for which the personal data will be stored, or, if not possible, the
+    criteria used to determine that period;
+  * the existence of the right to request from the controller rectification or erasure of personal data, or
+    restriction of processing of personal data concerning the data subject, or to object to such processing;
+  * the existence of the right to lodge a complaint with a supervisory authority;
+  * where the personal data are not collected from the data subject, any available information as to their
+    source;
+  * the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) of
+    the GDPR and, at least in those cases, meaningful information about the logic involved, as well as the
+    significance and envisaged consequences of such processing for the data subject.
+* Furthermore, the data subject shall have a right to obtain information as to whether personal data are
+  transferred to a third country or to an international organisation. Where this is the case, the data subject
+  shall have the right to be informed of the appropriate safeguards relating to the transfer. If a data
+  subject wishes to avail himself of this right of access, he or she may, at any time, contact any employee of
+  the controller.
+* **c) Right to rectification (Art. 16 GDPR)** Each data subject shall have the right granted by the European
+  legislator to obtain from the controller without undue delay the rectification of inaccurate personal data
+  concerning him or her. Taking into account the purposes of the processing, the data subject shall have the
+  right to have incomplete personal data completed, including by means of providing a supplementary
+  statement. If a data subject wishes to exercise this right to rectification, he or she may, at any time,
+  contact any employee of the controller.
+* **d) Right to erasure (Right to be forgotten, Art. 17 GDPR)** Each data subject shall have the right granted
+  by the European legislator to obtain from the controller the erasure of personal data concerning him or her
+  without undue delay, and the controller shall have the obligation to erase personal data without undue delay
+  where one of the following grounds applies, as long as the processing is not necessary:
+    * The personal data are no longer necessary in relation to the purposes for which they were collected or
+      otherwise processed.
+    * The data subject withdraws consent to which the processing is based according to point (a) of Article
+      6(1) of the GDPR, or point (a) of Article 9(2) of the GDPR, and where there is no other legal ground for
+      the processing.
+    * The data subject objects to the processing pursuant to Article 21(1) of the GDPR and there are no
+      overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant
+      to Article 21(2) of the GDPR.
+    * The personal data have been unlawfully processed.
+    * The personal data must be erased for compliance with a legal obligation in Union or Member State law to
+      which the controller is subject.
+    * The personal data have been collected in relation to the offer of information society services referred
+      to in Article 8(1) of the GDPR.
+* If one of the aforementioned reasons applies, and a data subject wishes to request the erasure of personal
+  data stored by \<enter company name\>, he or she may, at any time, contact any employee of the
+  controller. An employee of \<enter company name\> shall promptly ensure that the erasure request is complied
+  with immediately. Where the controller has made personal data public and is obliged pursuant to Article
+  17(1) to erase the personal data, the controller, taking account of available technology and the cost of
+  implementation, shall take reasonable steps, including technical measures, to inform other controllers
+  processing the personal data that the data subject has requested erasure by such controllers of any links
+  to, or copy or replication of, those personal data, as far as processing is not required. An employees of
+  \<enter company name\> will arrange the necessary measures in individual cases.
+* **e) Right of restriction of processing (Art. 18 GDPR)** Each data subject shall have the right granted by
+  the European legislator to obtain from the controller restriction of processing where one of the following
+  applies:
+  * The accuracy of the personal data is contested by the data subject, for a period enabling the controller
+    to verify the accuracy of the personal data.
+  * The processing is unlawful and the data subject opposes the erasure of the personal data and requests
+    instead the restriction of their use instead.
+  * The controller no longer needs the personal data for the purposes of the processing, but they are required
+    by the data subject for the establishment, exercise or defence of legal claims.
+  * The data subject has objected to processing pursuant to Article 21(1) of the GDPR pending the verification
+    whether the legitimate grounds of the controller override those of the data subject.
+* If one of the aforementioned conditions is met, and a data subject wishes to request the restriction of the
+  processing of personal data stored by us, he or she may at any time contact any employee of the
+  controller. The employee of \<enter company name\> will arrange the restriction of the processing.
+* **f) Right to data portability (Art. 20 GDPR)** Each data subject shall have the right granted by the
+  European legislator, to receive the personal data concerning him or her, which was provided to a controller,
+  in a structured, commonly used and machine-readable format. He or she shall have the right to transmit those
+  data to another controller without hindrance from the controller to which the personal data have been
+  provided, as long as the processing is based on consent pursuant to point (a) of Article 6(1) of the GDPR or
+  point (a) of Article 9(2) of the GDPR, or on a contract pursuant to point (b) of Article 6(1) of the GDPR,
+  and the processing is carried out by automated means, as long as the processing is not necessary for the
+  performance of a task carried out in the public interest or in the exercise of official authority vested in
+  the controller. Furthermore, in exercising his or her right to data portability pursuant to Article 20(1) of
+  the GDPR, the data subject shall have the right to have personal data transmitted directly from one
+  controller to another, where technically feasible and when doing so does not adversely affect the rights and
+  freedoms of others. In order to assert the right to data portability, the data subject may at any time
+  contact any employee of \<enter company name\>.
+* **g) Right to object (Art. 21 GDPR)** Each data subject shall have the right granted by the European
+  legislator to object, on grounds relating to his or her particular situation, at any time, to processing of
+  personal data concerning him or her, which is based on point (e) or (f) of Article 6(1) of the GDPR. This
+  also applies to profiling based on these provisions. \<enter company name\> shall no longer process the
+  personal data in the event of the objection, unless we can demonstrate compelling legitimate grounds for the
+  processing which override the interests, rights and freedoms of the data subject, or for the establishment,
+  exercise or defence of legal claims. If we processes personal data for direct marketing purposes, the data
+  subject shall have the right to object at any time to processing of personal data concerning him or her for
+  such marketing. This applies to profiling to the extent that it is related to such direct marketing. If the
+  data subject objects to the processing for direct marketing purposes, we will no longer process the personal
+  data for these purposes. In addition, the data subject has the right, on grounds relating to his or her
+  particular situation, to object to processing of personal data concerning him or her for scientific or
+  historical research purposes, or for statistical purposes pursuant to Article 89(1) of the GDPR, unless the
+  processing is necessary for the performance of a task carried out for reasons of public interest. In order
+  to exercise the right to object, the data subject may contact any employee of \<enter company name\>. In
+  addition, the data subject is free in the context of the use of information society services, and
+  notwithstanding Directive 2002/58/EC, to use his or her right to object by automated means using technical
+  specifications.
+* **h) Automated individual decision-making, including profiling** Each data subject shall have the right
+  granted by the European legislator not to be subject to a decision based solely on automated processing,
+  including profiling, which produces legal effects concerning him or her, or similarly significantly affects
+  him or her, as long as the decision (1) is not is necessary for entering into, or the performance of, a
+  contract between the data subject and a data controller, or (2) is not authorised by Union or Member State
+  law to which the controller is subject and which also lays down suitable measures to safeguard the data
+  subject's rights and freedoms and legitimate interests, or (3) is not based on the data subject's explicit
+  consent. If the decision (1) is necessary for entering into, or the performance of, a contract between the
+  data subject and a data controller, or (2) it is based on the data subject's explicit consent, \<enter
+  company name\> shall implement suitable measures to safeguard the data subject's rights and freedoms and
+  legitimate interests, at least the right to obtain human intervention on the part of the controller, to
+  express his or her point of view and contest the decision. If the data subject wishes to exercise the rights
+  concerning automated individual decision-making, he or she may, at any time, contact any employee of \<enter
+  company name\>.
+* **i) Right to withdraw data protection consent** Each data subject shall have the right granted by the
+  European legislator to withdraw his or her consent to processing of his or her personal data at any time. If
+  the data subject wishes to exercise the right to withdraw the consent, he or she may, at any time, contact
+  any employee of \<enter company name\>.
+
+You can also contact a supervisory authority with a complaint at any time, e.g. the supervisory authority of
+the state of your residence or the authority that oversees \<enter company name\>.
+
+You can find a list of supervisory authorities (for the non-public area) at [this
+link](https://www.bfdi.bund.de/DE/Service/Anschriften/Laender/Laender-node.html).
+
+## 8. Data protection for applications and the application procedures
+
+The data controller shall collect and process the personal data of applicants for the purpose of the
+processing of the application procedure. The processing may also be carried out electronically. This is the
+case, in particular, if an applicant submits corresponding application documents by e-mail or by means of a
+web form on the website to the controller. If the data controller concludes an employment contract with an
+applicant, the submitted data will be stored for the purpose of processing the employment relationship in
+compliance with legal requirements. If no employment contract is concluded with the applicant by the
+controller, the *application documents shall be automatically erased six months after notification of the
+refusal decision*, provided that no other legitimate interests of the controller are opposed to the
+erasure. Other legitimate interest in this relation is, e.g. a burden of proof in a procedure under the
+General Equal Treatment Act (AGG).
+
+## 9. Legal basis for the processing
+
+Art. 6(1) lit. a GDPR serves as the legal basis for processing operations for which we obtain consent for a
+specific processing purpose. If the processing of personal data is necessary for the performance of a contract
+to which the data subject is party, as is the case, for example, when processing operations are necessary for
+the supply of goods or to provide any other service, the processing is based on Article 6(1) lit. b GDPR. The
+same applies to such processing operations which are necessary for carrying out pre-contractual measures, for
+example in the case of inquiries concerning our products or services. Is our company subject to a legal
+obligation by which processing of personal data is required, such as for the fulfillment of tax obligations,
+the processing is based on Art. 6(1) lit. c GDPR. In rare cases, the processing of personal data may be
+necessary to protect the vital interests of the data subject or of another natural person. This would be the
+case, for example, if a visitor were injured in our company and his name, age, health insurance data or other
+vital information would have to be passed on to a doctor, hospital or other third party. Then the processing
+would be based on Art. 6(1) lit. d GDPR. Finally, processing operations could be based on Article 6(1) lit. f
+GDPR. This legal basis is used for processing operations which are not covered by any of the abovementioned
+legal grounds, if processing is necessary for the purposes of the legitimate interests pursued by our company
+or by a third party, except where such interests are overridden by the interests or fundamental rights and
+freedoms of the data subject which require protection of personal data. Such processing operations are
+particularly permissible because they have been specifically mentioned by the European legislator. He
+considered that a legitimate interest could be assumed if the data subject is a client of the controller
+(Recital 47 Sentence 2 GDPR).
+
+## 10. The legitimate interests pursued by the controller or by a third party
+
+Where the processing of personal data is based on Article 6(1) lit. f GDPR our legitimate interest is to carry
+out our business in favor of the well-being of all our employees and the shareholders.
+
+## 11. Period for which the personal data will be stored
+
+The criteria used to determine the period of storage of personal data is the respective statutory retention
+period. After expiration of that period, the corresponding data is routinely deleted, as long as it is no
+longer necessary for the fulfillment of the contract or the initiation of a contract.
+
+## 12. Provision of personal data as statutory or contractual requirement; Requirement necessary to enter into a contract; Obligation of the data subject to provide the personal data; possible consequences of failure to provide such data
+
+We clarify that the provision of personal data is partly required by law (e.g. tax regulations) or can also
+result from contractual provisions (e.g. information on the contractual partner). Sometimes it may be
+necessary to conclude a contract that the data subject provides us with personal data, which must subsequently
+be processed by us. The data subject is, for example, obliged to provide us with personal data when our
+company signs a contract with him or her. The non-provision of the personal data would have the consequence
+that the contract with the data subject could not be concluded. Before personal data is provided by the data
+subject, the data subject must contact any employee. The employee clarifies to the data subject whether the
+provision of the personal data is required by law or contract or is necessary for the conclusion of the
+contract, whether there is an obligation to provide the personal data and the consequences of non-provision of
+data.
+
+## 13. IT-Security
+
+To protect the security of your data during transmission, we use state-of-the-art encryption methods (such as
+SSL) via HTTPS.
+
+## 14. Existence of automated decision-making
+
+\<enter company name\> does not perform automatic decision-making or profiling.
+
+## 15\. Revision of this privacy policy
+
+We reserve the right to amend this privacy policy so that it always complies with current legal requirements
+or to implement changes to our services in the privacy policy, e.g. when introducing new services. Your next
+visit will be subject to the new privacy policy.
diff --git a/openregulatory/templates/data_protection/employee-data-protection-and-confidentiality-agreement.md b/openregulatory/templates/data_protection/employee-data-protection-and-confidentiality-agreement.md
new file mode 100644
index 00000000..fbc93bc0
--- /dev/null
+++ b/openregulatory/templates/data_protection/employee-data-protection-and-confidentiality-agreement.md
@@ -0,0 +1,174 @@
+> Note that this template includes legal provisions for Germany by referencing the German Federal Data
+> Protection Act (BDSG). If your company is based anywhere else, you should customize the contents before
+> using the template.
+
+# Data Protection and Confidentiality Agreement
+
+As part of your employment, you may be instructed to process personal data or potentially personal data that
+has been entrusted to you in accordance with the data protection regulations. To that end, you are provided
+with an overview of the regulations relevant to your obligation. Data which you have become aware of during
+the performance of your duties must not be misused for your own or any other purposes. This obligation remains
+in force even after the termination of your employment. Deliberate or negligent breaches can have legal
+consequences.
+
+Personal data is all information related to an identified or identifiable person. It may not be collected,
+used, passed on or otherwise processed without authorization. Personal data may only be processed in line with
+company instructions. In addition to instructions from a supervisor, the following are regarded as
+instructions: documents of the company"s quality management system, other operational documentation, flow
+charts, company agreements or employee manuals.
+
+***
+
+I, \<employee name\>
+
+hereby commit to keep strictest confidentiality with respect to personal data and to process it exclusively
+according to the instructions of \<enter company name\>. I hereby further commit to keep strictest
+confidentiality with respect to the personal data I shall collect, process, or access in the scope of my
+activities for \<enter company name\>, and to refrain from disclosing them to any other natural or legal
+person, including other employees of \<enter company name\>, unless disclosure is explicitly authorized by
+instructions of the employer, contract or law, or unless disclosure is necessary to fulfill the instructions
+of \<enter company name\>.
+
+For instance, I am not allowed to use mobile data media, take printed copies home with me, or pass on personal
+passwords to third parties. Further instructions on what has to be observed in terms of data protection law
+can be found, inter alia, in:
+
+* The company"s technical and organizational measures
+* Company forms on employee obligations with regards to the handling of hardware
+* The company"s list of data processing activities
+* \<add anything else relevant here, e.g. authorization concept for software systems\>
+
+This non-disclosure and confidentiality obligation continues to apply even after my employment with \<enter
+company name\> has ended.
+
+I am aware that any infringement against this obligation or of applicable data protection law such as Art. 83
+of the European General Data Protection Regulation (GDPR), §§ 42 and 43 of the German Federal Data Protection
+Act ("Bundesdatenschutzgesetz", BDSG) or other applicable European or national legal provisions may result in
+serious fines, monetary or prison sentences and may possibly cause damage to natural or legal persons,
+including the employer. In addition, infringement against this obligation may also constitute a breach of
+obligations under the employment contract or of specific obligations for confidentiality and may, for example,
+lead to a formal warning, a termination in due time or without notice or to an obligation to pay for
+compensation. Legal consequences of a breach can also entail claims for damages against me personally by the
+persons to whom such data refers. In these cases, I may be liable without limitation with all my assets and
+without the possibility of residual debt discharge in the course of insolvency proceedings. Other obligations
+of secrecy, such as those arising from the employment contract, continue to exist alongside this obligation.
+
+I have read and understood this obligation to maintain confidentiality and to comply with data protection
+regulations:
+
+\<Place, date and signature of employee\>\
+\<Place, date and signature of supervisor\>
+
+I confirm that I have been informed about the meaning and relevance of this data protection obligation. I have
+been given the opportunity to receive a copy of this form as well as further information on data protection
+and the text of Art. 29 GDPR, Art. 83 para. 4 - 6 GDPR, Art. 42 para. 1 and 2 BDSG and Art. 43 para. 1 and 2
+BDSG.
+
+\<Place, date and signature of employee\>\
+\<Place, date and signature of supervisor\>
+
+---
+
+## Annex: Further information on data protection
+
+* **Processing** within the EU General Data Protection Regulation (DSGVO) means any process or series of
+  operations performed with or without the aid of automated processes in connection with personal data such as
+  collection, organization, ordering, storage, adaptation, alteration, reading, querying, use, disclosure
+  through transmission, dissemination or other form of provision, matching or linking, restriction, erasure or
+  destruction. Any processing of personal data must be carried out according to a valid legal basis out of
+  those recognized by art. 6 GDPR and only for the purpose they have been collected for.
+
+* **Personal data** within the meaning of the GDPR are all information relating to an identified or
+  identifiable natural person; a natural person is considered as identifiable if it can be directly or
+  indirectly identified, in particular by association with an identifier such as a name, an identification
+  number, location data, an online identifier or one or more special features, the expression of the physical,
+  physiological, genetic, mental, economic, cultural or social identity of this natural person. The principles
+  of the European General Data Protection Regulation (GDPR) for the processing of personal data must be
+  adhered to; they are laid down in Art. 5 para. 1 GDPR and essentially contain the following obligations.
+
+Personal data must be
+
+1. processed lawfully, fairly and in a transparent manner in relation to the data subject ("lawfulness,
+   fairness and transparency");
+2. collected for specified, explicit and legitimate purposes and not further processed in a manner that is
+   incompatible with those purposes; further processing for archiving purposes in the public interest,
+   scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1),
+   not be considered to be incompatible with the initial purposes ("purpose limitation");
+3. adequate, relevant and limited to what is necessary in relation to the purposes for which they are
+   processed ("data minimization");
+4. accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal
+   data that are inaccurate, having regard to the purposes for which they are processed, are erased or
+   rectified without delay ("accuracy");
+5. kept in a form which permits identification of data subjects for no longer than is necessary for the
+   purposes for which the personal data are processed; personal data may be stored for longer periods insofar
+   as the personal data will be processed solely for archiving purposes in the public interest, scientific or
+   historical research purposes or statistical purposes in accordance with Article 89(1) subject to
+   implementation of the appropriate technical and organizational measures required by this Regulation in
+   order to safeguard the rights and freedoms of the data subject ("storage limitation");
+6. processed in a manner that ensures appropriate security of the personal data, including protection against
+   unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate
+   technical or organizational measures ("integrity and confidentiality"). \
+
+**Art. 29 GDPR: Processing under the authority of the controller or processor**
+
+The processor and any person acting under the authority of the controller or of the processor, who has access
+to personal data, shall not process those data except on instructions from the controller, unless required to
+do so by Union or Member State law.
+
+**Art. 83 GDPR: General conditions for imposing administrative fines**
+
+(4) Infringements of the following provisions shall, in accordance with paragraph 2, be subject to
+administrative fines up to 10.000.000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide
+annual turnover of the preceding financial year, whichever is higher:
+
+1. the obligations of the controller and the processor pursuant to Articles 8, 11, 25 to 39 and 42 and 43;
+2. the obligations of the certification body pursuant to Articles 42 and 43;
+3. the obligations of the monitoring body pursuant to Article 41(4).
+
+(5) Infringements of the following provisions shall, in accordance with paragraph 2, be subject to
+administrative fines up to 20.000.000 EUR, or in the case of an undertaking, up to 4 % of the total worldwide
+annual turnover of the preceding financial year, whichever is higher:
+
+1. the basic principles for processing, including conditions for consent, pursuant to Articles 5, 6, 7 and 9;
+2. the data subjects" rights pursuant to Articles 12 to 22;
+3. the transfers of personal data to a recipient in a third country or an international organization pursuant
+   to Art. 44 to 49;
+4. any obligations pursuant to Member State law adopted under Chapter IX;
+5. non-compliance with an order or a temporary or definitive limitation on processing or the suspension of
+   data flows by the supervisory authority pursuant to Article 58(2) or failure to provide access in violation
+   of Article 58(1).
+
+(6) Non-compliance with an order by the supervisory authority as referred to in Article 58(2) shall, in
+accordance with paragraph 2 of this Article, be subject to administrative fines up to 20 000 000 EUR, or in
+the case of an undertaking, up to 4 % of the total worldwide annual turnover of the preceding financial year,
+whichever is higher.
+
+**§ 42 BDSG: Penal provisions**
+
+(1) The following actions done deliberately and without authorization with regard to the personal data of a
+large number of people which are not publicly accessible shall be punishable with imprisonment of up to three
+years or a fine:
+
+1. transferring the data to a third party or
+2. otherwise making them accessible
+
+for commercial purposes.
+
+(2) The following actions done with regard to personal data which are not publicly accessible shall be
+punishable with imprisonment of up to two years or a fine:
+
+1. processing without authorization, or
+2. fraudulently acquiring
+
+and doing so in return for payment or with the intention of enriching oneself or someone else or harming
+someone.
+
+**§ 43 BDSG: Provisions on administrative fines**
+
+(1) Intentionally or negligently engaging in the following shall be deemed an administrative offense:
+
+1. in violation of Section 30 (1) failing to treat a request for information properly, or
+2. in violation of Section 30 (2), first sentence, failing to inform a consumer or doing so incorrectly,
+   incompletely or too late.
+
+(2) An administrative offense may be punished by a fine of up to fifty thousand euros.
diff --git a/openregulatory/templates/data_protection/list-of-data-processing-activities.md b/openregulatory/templates/data_protection/list-of-data-processing-activities.md
new file mode 100644
index 00000000..e141527a
--- /dev/null
+++ b/openregulatory/templates/data_protection/list-of-data-processing-activities.md
@@ -0,0 +1,157 @@
+# List of Data Processing Activities
+
+> This template is supposed to give you an idea of the structure. Don't use word - this is thought as an excel
+> / sheets file.  Think of the sub-sections below as different tabs in your excel sheet.
+>
+> Disclaimer: data privacy documentation should usually be written in the official language of your EU member
+> state. Most likely, you should translate this template accordingly. In German, people refer to this
+> typically as the 'Verzeichnis der Verarbeitungstätigkeiten'...
+
+## Data Processing Activities
+
+> Note that this tab should exist twice: one time for internal processing activities and one time for external
+> ones. *Internal* processing refers to your internal data that third parties may process on your behalf (for
+> example: your tax accountant, your cloud provider, providers of all the tools you use in your
+> company). *External* processing refers to data of third parties that you process on their behalf (for
+> example: customer data that is transferred to your servers to be analyzed by your brand-new AI algorithm).
+
+***Categories:** ID - Controller - Controller Address - Controller Contact Details - Legal Basis - Processing
+Purpose - Category of Data - Data Subjects - Start Date of Processing - End Date of Processing - Processor -
+Processor Address - Processor Contact Details - Legal Basis - Threshold Analysis - DPIA - Description of
+TOMs - Deletion Period - Transfer to Third Countries - Safeguards - Commentary*
+
+> Consider that you will have a ton more data processing activities than categories. Write your categories as
+> columns and processing activities as rows (the table in this template is transposed (rows and columns
+> flipped) due to formatting reasons).
+
+| Categories                  | Data Processing Example #1: Processing of Health Data by a Cloud Provider (Internal)                                                                                                                                                                              | Data Processing Example #2: Processing of Applicant Data by a Software Tool Provider (Internal)                               | Data Processing Example #3: Processing of Health Data by Your Company as Clinical Decision-Support (External) | (...) |
+|-----------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------|-------|
+| ID                          | 1                                                                                                                                                                                                                                                                 | 2                                                                                                                             | 3                                                                                                             |       |
+| Controller                  | Example GmbH                                                                                                                                                                                                                                                      | Example GmbH                                                                                                                  | Berlin-Based Example Customer                                                                                 |       |
+| Controller Address          | Example Street 123<br>10000 Berlin<br>Germany                                                                                                                                                                                                                     | Example Street 123<br>10000 Berlin<br>Germany                                                                                 | (...)                                                                                                         |       |
+| Controller Contact Details  | John Doe<br>john.doe@example.com                                                                                                                                                                                                                                  | John Doe<br>john.doe@example.com                                                                                              | (...)                                                                                                         |       |
+| Legal Basis                 | Commissioned Data Processing<br>(Art. 6 Sect. 1 lit. b) GDPR)                                                                                                                                                                                                     | Pre-Contractual Measures<br>(Art. 6 Sect. 1 lit. b) GDPR)                                                                     | Commissioned Data Processing<br>(Art. 6 Sect. 1 lit. b) GDPR)                                                 |       |
+| Processing Purpose          | Provision of Cloud Services                                                                                                                                                                                                                                       | Management of Applicant Data                                                                                                  | Provision of Decision-Support for Clinical Diagnoses                                                          |       |
+| Category of Data            | Patient Data (e.g. DICOM image data and clinical information)                                                                                                                                                                                                     | Applicant Data (e.g. CV, cover letter, reference documents)                                                                   | Patient Data (e.g. DICOM image data and clinical information)                                                 |       |
+| Data Subjects               | Patients that undergo CT lung cancer screening                                                                                                                                                                                                                    | Applicants to Example GmbH                                                                                                    | Patients that undergo CT lung cancer screening                                                                |       |
+| Start Date of Processing    | 01.08.2021                                                                                                                                                                                                                                                        | 01.01.2021                                                                                                                    | 01.08.2021                                                                                                    |       |
+| End Date of Processing      | N/A                                                                                                                                                                                                                                                               | N/A                                                                                                                           | N/A                                                                                                           |       |
+| Processor                   | Berlin-Based Example Cloud Provider                                                                                                                                                                                                                               | California-Based Example Software Provider                                                                                    | Example GmbH                                                                                                  |       |
+| Processor Address           | (...)                                                                                                                                                                                                                                                             | (...)                                                                                                                         | Example Street 123<br>10000 Berlin<br>Germany                                                                 |       |
+| Processor Contact Details   | (...)                                                                                                                                                                                                                                                             | (...)                                                                                                                         | John Doe<br>john.doe@example.com                                                                              |       |
+| Legal Basis                 | Commissioned Data Processing (Art. 6 Sect. 1 lit. b) GDPR)                                                                                                                                                                                                        | Commissioned Data Processing (Art. 6 Sect. 1 lit. b) GDPR)                                                                    | Commissioned Data Processing (Art. 6 Sect. 1 lit. b) GDPR)                                                    |       |
+| Threshold Analysis          | Acceptable                                                                                                                                                                                                                                                        | Acceptable                                                                                                                    | N/A                                                                                                           |       |
+| DPIA                        | N/A                                                                                                                                                                                                                                                               | N/A                                                                                                                           | N/A                                                                                                           |       |
+| Description of TOMs         | Entry Control: locked building, documented key assignment (..)<br>Access Control: central password authentication incl. 2FA (...)<br>Usage Control: role-based authorization (...)<br>Availability: uninterrupted power supply, continuous backups (...)<br>(...) | (...)                                                                                                                         | (...)                                                                                                         |       |
+| Deletion Period             | 30 days after data ingestion                                                                                                                                                                                                                                      | 6 months                                                                                                                      | 30 days after data ingestion                                                                                  |       |
+| Transfer to Third Countries | No                                                                                                                                                                                                                                                                | United States of America (USA)                                                                                                | No                                                                                                            |       |
+| Safeguards                  | N/A                                                                                                                                                                                                                                                               | EU Model Contract Clauses                                                                                                     | N/A                                                                                                           |       |
+| Comment                     |                                                                                                                                                                                                                                                                   | Note that after ECJ Schrems II ruling, model contract clauses alone are not sufficient to safeguard data transfer to the U.S. |                                                                                                               |       |
+
+## Threshold Analysis and Data Protection Impact Assessment
+
+> Note that it is the responsibility of the controller to carry out a DPIA (Art. 35 GDPR)
+>
+> Optionally, you can split this section into two separate tabs.
+>
+> Reasoning: whenever a risk is deemed acceptable in a previous section, the documentation ends right
+> there. For example, if the overall severity and probability of a risk are deemed acceptable, you don't have
+> to dive into further evaluation criteria of the next section or let alone start the DPIA for this
+> risk. Sections are shown in the text below in brackets - use different formatting when you adopt this
+> template).
+>
+> As part of your DPIA, you typically analyze several risk causes. More risk examples are listed in the risk
+> methodology section.
+
+**Categories TA:** *(Risk Identification) - Processor - Processing Purpose - Risk Cause - Risk Description -
+(Initial Risk Assessment) - Severity - Probability - Assessment - (Further Evaluation Criteria: Special
+Processing) - Processing large quantities of personal data - Processing affects a large number of people - Use
+of new technologies - Processing hampers the exertion of data subject rights - Processing hampers the use of
+services or exertion of contracts for data subjects - Processing of data of vulnerable persons - (Further
+Evaluation Criteria: Automated Decision-Making) - By systematic assessment of personal characteristics based
+on profiling - By processing special categories of personal data - (Responsible data protection authority
+deemed processing high-risk)*
+
+**Categories DPIA:** *Planned additional measures - (Re-Evaluation) - Severity after measures - Probability
+after measures - New assessment - (Implementation) - Responsible - Status - Date of Implementation -
+Notification of Authorities*
+
+| Categories                                                                        | Data Processing Example #1: Processing of Health Data by a Cloud Provider (Internal)             | Data Processing Example #2: Processing of Applicant Data by a Software Tool Provider (Internal) | (...) |
+|-----------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|-------|
+| ***Threshold Analysis***                                                          | -                                                                                                | -                                                                                               | -     |
+| ***Risk Identification***                                                         | -                                                                                                | -                                                                                               | -     |
+| Processor                                                                         | Berlin-Based Example Cloud Provider                                                              | California-Based Example Software Provider                                                      |       |
+| Processing Purpose                                                                | Provision of Cloud Services                                                                      | Management of Applicant Data                                                                    |       |
+| Risk Cause                                                                        | Unauthorized access                                                                              | Unauthorized access                                                                             |       |
+| Risk Description                                                                  | Sensitive patient data could be identified by third-parties, leading to a risk of identity theft | Applicant data could be identified by third-parties, leading to a risk of identity theft        |       |
+| ***Initial Risk Assessment***                                                     | -                                                                                                | -                                                                                               | -     |
+| Severity                                                                          | S4                                                                                               | S3                                                                                              |       |
+| Probability                                                                       | P2                                                                                               | P2                                                                                              |       |
+| Assessment                                                                        | Unacceptable                                                                                     | Acceptable                                                                                      |       |
+| ***Further Criteria: Special Processing***                                        | -                                                                                                | -                                                                                               | -     |
+| Processing large quantities of personal data                                      | No                                                                                               | -                                                                                               |       |
+| Processing affects large numbers of people                                        | No                                                                                               | -                                                                                               |       |
+| Use of new technologies                                                           | No                                                                                               | -                                                                                               |       |
+| Processing hampers the exertion of data subject rights                            | No                                                                                               | -                                                                                               |       |
+| Processing hampers the use of services or exertion of contracts for data subjects | No                                                                                               | -                                                                                               |       |
+| Processing of data of vulnerable persons                                          | No                                                                                               | -                                                                                               |       |
+| ***Further Criteria: Automated Decision-Making (ADM)***                           | -                                                                                                | -                                                                                               | -     |
+| ADM by systematic assessment of personal characteristics based on profiling       | No                                                                                               | -                                                                                               |       |
+| ADM by processing special categories of personal data                             | No                                                                                               | -                                                                                               |       |
+| *Responsible Data Protection Authority deems processing high-risk*                | No                                                                                               | -                                                                                               |       |
+| ***Data Protection Impact Assessment***                                           | -                                                                                                | -                                                                                               | -     |
+| Planned additional measures                                                       | -                                                                                                | -                                                                                               |       |
+| ***Re-Evaluation***                                                               | -                                                                                                | -                                                                                               | -     |
+| Severity after measures                                                           | -                                                                                                | -                                                                                               |       |
+| Probability after measures                                                        | -                                                                                                | -                                                                                               |       |
+| New assessment after measures                                                     | -                                                                                                | -                                                                                               |       |
+| ***Implementation***                                                              | -                                                                                                | -                                                                                               | -     |
+| Responsible Role                                                                  | -                                                                                                | -                                                                                               |       |
+| Status of Implementation                                                          | -                                                                                                | -                                                                                               |       |
+| Date of Implementation                                                            | -                                                                                                | -                                                                                               |       |
+| Notification to Authorities                                                       | -                                                                                                | -                                                                                               |       |
+| Comment                                                                           |                                                                                                  |                                                                                                 |       |
+
+## Risk Methodology
+
+> This field should provide the taxonomy and an overview of the possible categories of content entered in the
+> previous tabs.
+
+**Possible categories of risk:**
+
+* Data loss (availability)
+* Unauthorized access (confidentiality)
+* Unauthorized modification (integrity)
+* Non-compliance (e.g. not deleting data)
+
+**Categories of data processed by the company:**
+
+* Employee data
+* Customer data (of commercial partners)
+* User data (of employees of partners)
+* Patient data
+
+| Degree of Severity | Social Damage (e.g. discrimination, loss of reputation)                                                                       | Financial Damage                         | Identity theft | Mortal Danger | Disclosure of Secrets                                                          |
+|--------------------|-------------------------------------------------------------------------------------------------------------------------------|------------------------------------------|----------------|---------------|--------------------------------------------------------------------------------|
+| S1: Low            | No or minor societal or economical disadvantages in daily life                                                                | In the scope of a one month salary       |                |               |                                                                                |
+| S2: Rather Low     | Societal or economical disadvantages can be noticed and lead to minor restrictions in daily life                              | In the scope of several months of salary |                |               |                                                                                |
+| S3: Rather high    | Implications for an entire part of daily life for a person affected (e.g. work place / professional environment)              | In the scope an annual salary            |                |               | Disclosure of secrets has implications for a part of life of a person affected |
+| S4: High           | Major disadvantages for an affected person across all fields of life (e.g. job loss or implications for personal surrounding) | Loss of all financial means              | Identity theft | Mortal danger | Geheimnisoffenbarung hat Auswirkungen auf das gesamte Leben des Betroffenen.   |
+
+| Probability of Occurrence | Future Estimate                                | Past Estimate                                      |
+|---------------------------|------------------------------------------------|----------------------------------------------------|
+| P1: Never                 | Event is unimaginable                          | Event has never occurred                           |
+| P2: Seldom                | Event may on average occur once every 10 years | Event has never occurred or more than 10 years ago |
+| P3: Rather unlikely       | Event may on average occur every 5-10 years    | Event has occurred in the last 5-10 years          |
+| P4: Rather likely         | Event may on average occur every 1-5 years     | Event has occurred in the last 1-5 years           |
+| P5: Frequently            | Event occurs at least once per year            | Event has occurred in the last year                |
+
+> Note: fields that are marked red symbolize a combined severity and probability that is unacceptable, yellow fields are acceptable.
+
+|                     | S1: Low       | S2: Rather Low | S3: Rather High | S4: High      |
+|---------------------|---------------|----------------|-----------------|---------------|
+| P5: Frequently      | S1P5 (yellow) | S2P5 (red)     | S3P5 (red)      | S4P5 (red)    |
+| P4: Rather likely   | S1P4 (yellow  | S2P4 (red)     | S3P4 (red)      | S4P4 (red)    |
+| P3: Rather unlikely | S1P3 (yellow) | S2P3 (yellow)  | S3P3 (red)      | S3P3 (red)    |
+| P2: Seldom          | S1P2 (yellow) | S2P2 (yellow)  | S3P2 (yellow)   | S4P2 (red)    |
+| P1: Never           | S1P1 (yellow) | S2P1 (yellow)  | S3P1 (yellow)   | S4P1 (yellow) |
diff --git a/openregulatory/templates/data_protection/technical-and-organizational-measures.md b/openregulatory/templates/data_protection/technical-and-organizational-measures.md
new file mode 100644
index 00000000..94d12d03
--- /dev/null
+++ b/openregulatory/templates/data_protection/technical-and-organizational-measures.md
@@ -0,0 +1,210 @@
+# \<Product Name\> - Technical and Organizational Measures
+
+## 1. General Considerations
+
+This data protection policy outlines the technical and organizational measures implemented for secure and
+compliant processing of personal data. It takes into account the rights of data subjects and requirements of
+the articles 24, 25, and 32 GDPR to the extent applicable.
+
+\<enter company name\> deals with three general categories of personal data:
+
+1. (...)
+2. (...)
+
+The following description of technical and organizational measures will be differentiated, where applicable,
+according to these categories of data.
+
+## 2. Organization
+
+\<enter company name\> appointed a data protection officer (DPO) who provides advice on data privacy issues,
+updates the team about changes in regulations and standards and, if required, supports with reviews and
+improvement of the measures. The DPO can be reached via \<enter email address\>.
+
+In the future, the company is going to create data privacy guidelines documented in the form of standard
+operating procedures (e.g. DPR-SOP) and templates.
+
+> Reference here your Information-Security-Management-System (ISMS) in place.
+
+## 3. Confidentiality
+
+### 3.1 Entry Control
+
+\<enter company name\> operates based on office premises that are not freely accessible. They are locked when
+employees are away. The company implemented the following measures:
+
+* Locked building
+* Locked office
+
+\<enter company name\> does not maintain servers or server rooms. (...)
+
+> If you operate your own server rooms, do your best at describing all security policies to prevent
+> unauthorized people from entering here.
+>
+> If you use a third party cloud provider, their policies here. Typically, they should provide you with loads
+> of material that is helpful for this exercise.
+>
+> If your users store data locally on their end devices - good for you. In that case, enter some description
+> of that and outline that no data leaves the end device.
+
+### 3.2 Access Control
+
+The company has implemented the following measures for access to software systems:
+
+(...)
+
+> Describe your access restrictions. Those are measures not only to prevent unauthorized people from entering
+> your offices, but also to prevent unauthorized (electronic) access. Some example measures:
+>
+> * For every employee, a personally assigned user is set up with a password bound to strict requirements (at
+>   least 14 characters long with special characters).
+> * Passwords must be unique and may not be used for other accounts. Passwords must be changed annually.
+> * Central authentication with username and password, incl. mandatory 2-factor authentication. Every user has
+>   to verify the account at least every 30 days.
+> * Access is monitored and logged, including unsuccessful login attempts.
+> * Access is automatically blocked by the system after XXX failed attempts.
+> * Only employees get access to the majority of files and systems and the extent of access can be determined
+>   selectively.
+
+### 3.3 Usage Control
+
+The company has implemented following measures when working within software systems:
+
+(...)
+
+> What are your policies when working with your internal systems? Some typical examples:
+>
+> * The password rules for access control must also be followed for usage control.
+> * Role-based authorization, administrative user profiles are kept to a minimum.
+> * User-dependent authentication with username and password.
+> * The use of personal data is limited, so that only authorized individuals can use the personal data
+>   necessary for their task (De Minimis Principle).
+> * Logging of usage and changes.
+> * Paperless work by principle and compliant destruction of paper documents with a shredder where applicable.
+
+### 3.4 Pseudonymization
+
+(...)
+
+> This is often an overshoot, but think of scenarios in which identifiable data is really not that
+> necessary. One common example:
+>
+> * Customer data is pseudonymized so far as the connection to the individual is not absolutely necessary for
+>   the result.
+
+### 3.5 Separation Control
+
+(...)
+
+> This typically applies to companies managing large amounts of data from various customers:
+>
+> * Separation of data is ensured for customer data based on software system management, e.g. through data
+>   storage in separate folders.
+
+## 4. Integrity
+
+### 4.1 Transfer Control
+
+Transfer control shall ensure that only authorized individuals can inspect personal data. Employee mobile
+devices must be encrypted if personal data is stored on them.
+
+(...)
+
+> How do you keep data safe in transmission? Some example measures:
+>
+> * The use of single USB flash drives or related data carrier tools is not allowed. Information should only
+>   be printed out if absolutely needed. Printed copies must be shredded immediately as soon as they are no
+>   longer needed.
+> * Home office policies (e.g. connect to VPN)
+
+### 4.2 Input Control
+
+The company has implemented the following measures for its software systems:
+
+* Traceability of inputs, changes, and deletions by personalized users
+* Traceability in assigning, changing, and deleting user authorizations
+
+> This applies to most cloud working environments (e.g. Google Drive, MS Sharepoint, Confluence, JIRA
+> etc.). Any other measures to add in your context?
+
+### 4.3 Availability and Reliability
+
+* Employees are provided equipment which is state-of-the-art. Example configuration: (...)
+* Personal data is processed on data processing systems that are subject to regular and documented patch
+  management. No systems may be linked on the network that are outside of the manufacturer’s maintenance
+  cycles (e.g. no Win95, XP, etc). Automatic updates are activated on the computers.
+* Continuous availability of high-speed internet is ensured. (Cloud system services can be used with any
+  internet connection.)
+* Continuous availability of data is guaranteed by means of redundant storage media and backups of systems
+  according to the latest technical standards.
+
+> Again, if you are using a large cloud provider, you can add more extensive policies and measures here, such
+> as for example:
+>
+> * Cloud provider data centers and server rooms are state of the art (temperature control, fire protection,
+>   water penetration, uninterrupted power supply (UPS) ensuring controlled shutdown without any loss of
+>   data).
+
+### 4.4 Product Development
+
+#### 4.4.1 Development Tools
+
+(...)
+
+> As before, think about your own organizational setup. How do you ensure safe development? Some examples:
+>
+> * Third party applications must be approved prior to use by (...) according to (...) to ensure compliance
+>   with quality management and data privacy requirements.
+> * Development tools must only be downloaded from secure sources (e.g., the manufacturer’s servers).
+> * Where possible, single-sign-on authentication is used for third party applications to allow for a complete
+>   and compliant access administration within the organization.
+> * Less secure third-party applications are disabled by administrator default configurations.
+
+#### 4.4.2 Privacy-Friendly Settings
+
+(...)
+
+> * Product development must take into account giving users the option of entering only the information
+>   necessary for the purpose of processing. Input fields with additional, unnecessary information should be
+>   avoided or at least designed as non-mandatory.
+> * By default, privacy-friendly settings must be preselected.
+
+### 4.6 Data Deletion
+
+The company implemented the following concept for automatic data deletion:
+
+| **Data category** | **Retention period**                                                                                         | **Responsible** |
+|-------------------|--------------------------------------------------------------------------------------------------------------|-----------------|
+| User data         | \<This period typically should be specified as part of the informed user consent\>                           |                 |
+| Customer data     | - Customer data after termination of contracts<br>- Lead contact data after 10 years of paused communication |                 |
+| Employee data     | Until end of employment                                                                                      |                 |
+| Applicant data    | Until 6 months after hiring decision or longer in case of employment                                         |                 |
+| Website data      | Deleted after every session                                                                                  | Automated       |
+
+## 5. Employee Workplace
+
+The company has implemented the following measures:
+
+* Employees must encrypt their hard drives with state-of-the-art encryption, e.g. Apple FileVault 2 for mac OS
+  or equivalent software for other operating systems.
+* The email account provider applies a default virus, spam and phishing filter to detect malicious software
+  and avert cyber attacks.
+* Employees are required to set up a completely closed firewall for their home office internet network.
+* Employees are obligated to clean their desk of any documents containing sensitive data, especially when
+  accessible by others.
+* The default option for screen savers must be set at the shortest time period until activation. When
+  temporarily leaving the workplace and hardware, employees should always lock their devices.
+
+## 6. Procedure for Regular Review, Assessment and Evaluation
+
+Data protection and IT security within the company is reviewed regularly and, based on these assessments,
+continuously improved. Internal auditing may include data privacy requirements such as:
+
+* Obligation of employees to maintain data secrecy, training and education.
+* Regular auditing of data processing procedures.
+* Procedures in case of data breaches and the protection of data subjects’ rights
+
+The company has implemented the following internal measures:
+
+* Appointment of a data protection officer
+* Regular auditing of procedures
+* Regular review of technical advancements in accordance with Article 32 GDPR
diff --git a/openregulatory/templates/general/checklist-mdr.md b/openregulatory/templates/general/checklist-mdr.md
new file mode 100644
index 00000000..d6ef48a4
--- /dev/null
+++ b/openregulatory/templates/general/checklist-mdr.md
@@ -0,0 +1,395 @@
+# Checklist: MDR General Safety and Performance Requirements
+
+## Chapter I: General Requirements
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 1 | Devices shall achieve the performance intended by their manufacturer and shall be designed and manufactured in such a way that, during normal conditions of use, they are suitable for their intended purpose. They shall be safe and effective and shall not compromise the clinical condition or the safety of patients, or the safety and health of users or, where applicable, other persons, provided that any risks which may be associated with their use constitute acceptable risks when weighed against the benefits to the patient and are compatible with a high level of protection of health and safety, taking into account the generally acknowledged state of the art. | Yes |  | ISO 14971:2019 | Intended Use<br>Risk Management Report<br>Clinical Evaluation Report |
+| 2 | The requirement in this Annex to reduce risks as far as possible means the reduction of risks as far as possible without adversely affecting the benefit-risk ratio. | Yes |  | ISO 14971:2019 | Risk Management Report |
+| 3 | Manufacturers shall establish, implement, document and maintain a risk management system. Risk management shall be understood as a continuous iterative process throughout the entire lifecycle of a device, requiring regular systematic updating. In carrying out risk management manufacturers shall: | Yes |  | ISO 14971:2019 | SOP Risk Management |
+| (a) | establish and document a risk management plan for each device; | Yes |  | ISO 14971:2019 | Risk Management Plan |
+| (b) | identify and analyze the known and foreseeable hazards associated with each device; | Yes |  | ISO 14971:2019 | Risk Table |
+| (c) | estimate and evaluate the risks associated with, and occurring during, the intended use and during reasonably foreseeable misuse; | Yes |  | ISO 14971:2019 | Risk Table |
+| (d) | eliminate or control the risks referred to in point (c) in accordance with the requirements of Section 4; | Yes |  | ISO 14971:2019 | Risk Table |
+| (e) | evaluate the impact of information from the production phase and, in particular, from the post-market surveillance system, on hazards and the frequency of occurrence thereof, on estimates of their associated risks, as well as on the overall risk, benefit-risk ratio and risk acceptability; and | Yes |  | ISO 14971:2019 | Risk Table<br>SOP Integrated Software Development |
+| (f) | based on the evaluation of the impact of the information referred to in point (e), if necessary amend control measures in line with the requirements of Section 4. | Yes |  | ISO 14971:2019 | Risk Table |
+| 4 | Risk control measures adopted by manufacturers for the design and manufacture of the devices shall conform to safety principles, taking account of the generally acknowledged state of the art. To reduce risks, Manufacturers shall manage risks so that the residual risk associated with each hazard as well as the overall residual risk is judged acceptable. In selecting the most appropriate solutions, manufacturers shall, in the following order of priority: | Yes |  | ISO 14971:2019 | Risk Table |
+| (a) | eliminate or reduce risks as far as possible through safe design and manufacture; | Yes |  | ISO 14971:2019 | Risk Table |
+| (b) | where appropriate, take adequate protection measures, including alarms if necessary, in relation to risks that cannot be eliminated; and | Yes |  | ISO 14971:2019 | Risk Table |
+| (c) | provide information for safety (warnings/precautions/contra-indications) and, where appropriate, training to users. | Yes |  | ISO 14971:2019 | Risk Table |
+| 5 | In eliminating or reducing risks related to use error, the manufacturer shall: |  |  |  |  |
+| (a) | reduce as far as possible the risks related to the ergonomic features of the device and the environment in which the device is intended to be used (design for patient safety), and | Yes |  | IEC 62366-1:2015 + COR1:2016 | Risk Table<br>Software Requirements List<br>Usability Evaluation Report |
+| (b) | give consideration to the technical knowledge, experience, education, training and use environment, where applicable, and the medical and physical conditions of intended users (design for lay, professional, disabled or other users). | Yes |  | IEC 62366-1:2015 + COR1:2016 | Intended Use<br>Risk Table |
+| 6 | The characteristics and performance of a device shall not be adversely affected to such a degree that the health or safety of the patient or the user and, where applicable, of other persons are compromised during the lifetime of the device, as indicated by the manufacturer, when the device is subjected to the stresses which can occur during normal conditions of use and has been properly maintained in accordance with the manufacturer’s instructions. | No | Software device |  |  |
+| 7 | Devices shall be designed, manufactured and packaged in such a way that their characteristics and performance during their intended use are not adversely affected during transport and storage, for example, through fluctuations of temperature and humidity, taking account of the instructions and information provided by the manufacturer. | No | Software device |  |  |
+| 8 | All known and foreseeable risks, and any undesirable side-effects, shall be minimized and be acceptable when weighed against the evaluated benefits to the patient and/or user arising from the achieved performance of the device during normal conditions of use. | Yes |  | ISO 14971:2019 | Clinical Evaluation Report |
+| 9 | For the devices referred to in Annex XVI, the general safety requirements set out in Sections 1 and 8 shall be understood to mean that the device, when used under the conditions and for the purposes intended, does not present a risk at all or presents a risk that is no more than the maximum acceptable risk related to the product’s use which is consistent with a high level of protection for the safety and health of persons. | No | Annex XVI does not apply |  |  |
+
+## Chapter II: Requirements Regarding Design and Manufacture
+
+### 2.1) Chemical, Physical and Biological Properties
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 10.1 | Devices shall be designed and manufactured in such a way as to ensure that the characteristics and performance requirements referred to in Chapter I are fulfilled. Particular attention shall be paid to: | No | Software device |  |  |
+| (a) | the choice of materials and substances used, particularly as regards toxicity and, where relevant, flammability; | No | Software device |  |  |
+| (b) | the compatibility between the materials and substances used and biological tissues, cells and body fluids, taking account of the intended purpose of the device and, where relevant, absorption, distribution, metabolism and excretion; | No | Software device |  |  |
+| (c) | the compatibility between the different parts of a device which consists of more than one implantable part; | No | Software device |  |  |
+| (d) | the impact of processes on material properties; | No | Software device |  |  |
+| (e) | where appropriate, the results of biophysical or modelling research the validity of which has been demonstrated beforehand; | No | Software device |  |  |
+| (f) | the mechanical properties of the materials used, reflecting, where appropriate, matters such as strength, ductility, fracture resistance, wear resistance and fatigue resistance; | No | Software device |  |  |
+| (g) | surface properties; and | No | Software device |  |  |
+| (h) | the confirmation that the device meets any defined chemical and/or physical specifications. | No | Software device |  |  |
+| 10.2 | Devices shall be designed, manufactured and packaged in such a way as to minimize the risk posed by contaminants and residues to patients, taking account of the intended purpose of the device, and to the persons involved in the transport, storage and use of the devices. Particular attention shall be paid to tissues exposed to those contaminants and residues and to the duration and frequency of exposure. | No | Software device |  |  |
+| 10.3 | Devices shall be designed and manufactured in such a way that they can be used safely with the materials and substances, including gases, with which they enter into contact during their intended use; if the devices are intended to administer medicinal products they shall be designed and manufactured in such a way as to be compatible with the medicinal products concerned in accordance with the provisions and restrictions governing those medicinal products and that the performance of both the medicinal products and of the devices is maintained in accordance with their respective indications and intended use. | No | Software device |  |  |
+
+### 2.2) Substances
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 10.4.1 | Devices shall be designed and manufactured in such a way as to reduce as far as possible the risks posed by substances or particles, including wear debris, degradation products and processing residues, that may be released from the device. Devices, or those parts thereof or those materials used therein that: | No | Software device |  |  |
+|  | — are invasive and come into direct contact with the human body, | No | Software device |  |  |
+|  | — (re)administer medicines, body liquids or other substances, including gases, to/from the body, or | No | Software device |  |  |
+|  | — transport or store such medicines, body fluids or substances, including gases, to be (re)administered to the body, | No | Software device |  |  |
+|  | shall only contain the following substances in a concentration that is above 0,1 % weight by weight (w/w) where justified pursuant to Section 10.4.2: | No | Software device |  |  |
+| (a) | substances which are carcinogenic, mutagenic or toxic to reproduction (‘CMR’), of category 1A or 1B, in accordance with Part 3 of Annex VI to Regulation (EC) No 1272/2008 of the European Parliament and of the Council (1), or | No | Software device |  |  |
+| (b) | substances having endocrine-disrupting properties for which there is scientific evidence of probable serious effects on human health and which are identified either in accordance with the procedure set out in Article 59 of Regulation (EC) No 1907/2006 of the European Parliament and of the Council (2) or, once a delegated act has been adopted by the Commission pursuant to the first subparagraph of Article 5(3) of Regulation (EU) No 528/2012 of the European Parliament and the Council (3), in accordance with the criteria that are relevant to human health amongst the criteria established therein. | No | Software device |  |  |
+| 10.4.2 | Justification regarding the presence of CMR and/or endocrine-disrupting substances: The justification for the presence of such substances shall be based upon: | No | Software device |  |  |
+| (a) | an analysis and estimation of potential patient or user exposure to the substance; | No | Software device |  |  |
+| (b) | an analysis of possible alternative substances, materials or designs, including, where available, information about independent research, peer-reviewed studies, scientific opinions from relevant scientific committees and an analysis of the availability of such alternatives; | No | Software device |  |  |
+| (c) | argumentation as to why possible substance and/ or material substitutes, if available, or design changes, if feasible, are inappropriate in relation to maintaining the functionality, performance and the benefit-risk ratios of the product; including taking into account if the intended use of such devices includes treatment of children or treatment of pregnant or breastfeeding women or treatment of other patient groups considered particularly vulnerable to such substances and/or materials; and | No | Software device |  |  |
+| (d) | where applicable and available, the latest relevant scientific committee guidelines in accordance with Sections 10.4.3. and 10.4.4. | No | Software device |  |  |
+| 10.4.3 | Guidelines on phthalates: For the purposes of Section 10.4., the Commission shall, as soon as possible and by 26 May 2018, provide the relevant scientific committee with a mandate to prepare guidelines that shall be ready before 26 May 2020. The mandate for the committee shall encompass at least a benefit-risk assessment of the presence of phthalates which belong to either of the groups of substances referred to in points (a) and (b) of Section 10.4.1. The benefit-risk assessment shall take into account the intended purpose and context of the use of the device, as well as any available alternative substances and alternative materials, designs or medical treatments. When deemed appropriate on the basis of the latest scientific evidence, but at least every five years, the guidelines shall be updated. | No | Software device |  |  |
+| 10.4.4 | Guidelines on other CMR and endocrine-disrupting substances:Subsequently, the Commission shall mandate the relevant scientific committee to prepare guidelines as referred to in Section 10.4.3. also for other substances referred to in points (a) and (b) of Section 10.4.1., where appropriate. | No | Software device |  |  |
+| 10.4.5 | Labelling: Where devices, parts thereof or materials are used therein as referred to in Section 10.4.1. contain substances referred to in points (a) or (b) of Section 10.4.1. in a concentration above 0,1 % weight by weight (w/w), the presence of those substances shall be labelled on the device itself and/or on the packaging for each unit or, where appropriate, on the sales packaging, with the list of such substances. If the intended use of such devices includes treatment of children or treatment of pregnant or breastfeeding women or treatment of other patient groups considered particularly vulnerable to such substances and/or materials, information on residual risks for those patient groups and, if applicable, on appropriate precautionary measures shall be given in the instructions for use. | No | Software device |  |  |
+| 10.5 | Devices shall be designed and manufactured in such a way as to reduce as far as possible the risks posed by the unintentional ingress of substances into the device taking into account the device and the nature of the environment in which it is intended to be used. | No | Software device |  |  |
+| 10.6 | Devices shall be designed and manufactured in such a way as to reduce as far as possible the risks linked to the size and the properties of particles which are or can be released into the patient’s or user’s body, unless they come into contact with intact skin only. Special attention shall be given to nanomaterials. | No | Software device |  |  |
+
+### 2.3) Infection and Microbiological Contamination
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 11.1 | Devices and their manufacturing processes shall be designed in such a way as to eliminate or to reduce as far as possible the risk of infection to patients, users and, where applicable, other persons. The design shall: | No | Software device |  |  |
+| (a) | reduce as far as possible and appropriate the risks from unintended cuts and pricks, such as needle stick injuries, | No | Software device |  |  |
+| (b) | allow easy and safe handling, | No | Software device |  |  |
+| (c) | reduce as far as possible any microbial leakage from the device and/or microbial exposure during use, and | No | Software device |  |  |
+| (d) | prevent microbial contamination of the device or its content such as specimens or fluids. | No | Software device |  |  |
+| 11.2 | Where necessary devices shall be designed to facilitate their safe cleaning, disinfection, and/or re-sterilization. | No | Software device |  |  |
+| 11.3 | Devices labelled as having a specific microbial state shall be designed, manufactured and packaged to ensure that they remain in that state when placed on the market and remain so under the transport and storage conditions specified by the manufacturer. | No | Software device |  |  |
+| 11.4 | Devices delivered in a sterile state shall be designed, manufactured and packaged in accordance with appropriate procedures, to ensure that they are sterile when placed on the market and that, unless the packaging which is intended to maintain their sterile condition is damaged, they remain sterile, under the transport and storage conditions specified by the manufacturer, until that packaging is opened at the point of use. It shall be ensured that the integrity of that packaging is clearly evident to the final user. | No | Software device |  |  |
+| 11.5 | Devices labelled as sterile shall be processed, manufactured, packaged and, sterilized by means of appropriate, validated methods. | No | Software device |  |  |
+| 11.6 | Devices intended to be sterilised shall be manufactured and packaged in appropriate and controlled conditions and facilities. | No | Software device |  |  |
+| 11.7 | Packaging systems for non-sterile devices shall maintain the integrity and cleanliness of the product and, where the devices are to be sterilised prior to use, minimise the risk of microbial contamination; the packaging system shall be suitable taking account of the method of sterilisation indicated by the manufacturer. | No | Software device |  |  |
+| 11.8 | The labelling of the device shall distinguish between identical or similar devices placed on the market in both a sterile and a non-sterile condition additional to the symbol used to indicate that devices are sterile. | No | Software device |  |  |
+| 12 | Devices incorporating a substance considered to be a medicinal product and devices that are composed of substances or of combinations of substances that are absorbed by or locally dispersed in the human body. | No | Software device |  |  |
+| 12.1 | In the case of devices referred to in the first subparagraph of Article 1(8), the quality, safety and usefulness of the substance which, if used separately, would be considered to be a medicinal product within the meaning of point (2) of Article 1 of Directive 2001/83/EC, shall be verified by analogy with the methods specified in Annex I to Directive 2001/83/EC, as required by the applicable conformity assessment procedure under this Regulation. | No | Software device |  |  |
+| 12.2 | Devices that are composed of substances or of combinations of substances that are intended to be introduced into the human body, and that are absorbed by or locally dispersed in the human body shall comply, where applicable and in a manner limited to the aspects not covered by this Regulation, with the relevant requirements laid down in Annex I to Directive 2001/83/EC for the evaluation of absorption, distribution, metabolism, excretion, local tolerance, toxicity, interaction with other devices, medicinal products or other substances and potential for adverse reactions, as required by the applicable conformity assessment procedure under this Regulation. | No | Software device |  |  |
+
+### 2.4) Devices Incorporating Materials of Biological Origin
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| :--- | :---------- | :--------- | :-------- | ------------------- | ---------------------- |
+| 13.1 | For devices manufactured utilizing derivatives of tissues or cells of human origin which are non-viable or are rendered non-viable covered by this Regulation in accordance with point (g) of Article 1(6), the following shall apply: | No | Software device |  |  |
+| (a) | donation, procurement and testing of the tissues and cells shall be done in accordance with Directive 2004/23/EC; | No | Software device |  |  |
+| (b) | processing, preservation and any other handling of those tissues and cells or their derivatives shall be carried out so as to provide safety for patients, users and, where applicable, other persons. In particular, safety with regard to viruses and other transmissible agents shall be addressed by appropriate methods of sourcing and by implementation of validated methods of elimination or inactivation in the course of the manufacturing process; | No | Software device |  |  |
+| (c) | the traceability system for those devices shall be complementary and compatible with the traceability and data protection requirements laid down in Directive 2004/23/EC and in Directive 2002/98/EC. | No | Software device |  |  |
+| 13.2 | For devices manufactured utilizing tissues or cells of animal origin, or their derivatives, which are non-viable or rendered non-viable the following shall apply: | No | Software device |  |  |
+| (a) | where feasible taking into account the animal species, tissues and cells of animal origin, or their derivatives, shall originate from animals that have been subjected to veterinary controls that are adapted to the intended use of the tissues. Information on the geographical origin of the animals shall be retained by manufacturers; | No | Software device |  |  |
+| (b) | sourcing, processing, preservation, testing and handling of tissues, cells and substances of animal origin, or their derivatives, shall be carried out so as to provide safety for patients, users and, where applicable, other persons. In particular safety with regard to viruses and other transmissible agents shall be addressed by implementation of validated methods of elimination or viral inactivation in the course of the manufacturing process, except when the use of such methods would lead to unacceptable degradation compromising the clinical benefit of the device; | No | Software device |  |  |
+| (c) | in the case of devices manufactured utilizing tissues or cells of animal origin, or their derivatives, as referred to in Regulation (EU) No 722/2012 the particular requirements laid down in that Regulation shall apply. | No | Software device |  |  |
+| 13.3 | For devices manufactured utilizing non-viable biological substances other than those referred to in Sections 13.1 and 13.2, the processing, preservation, testing and handling of those substances shall be carried out so as to provide safety for patients, users and, where applicable, other persons, including in the waste disposal chain. In particular, safety with regard to viruses and other transmissible agents shall be addressed by appropriate methods of sourcing and by implementation of validated methods of elimination or inactivation in the course of the manufacturing process. | No | Software device |  |  |
+
+### 2.5) Construction of Devices and Interaction with their Environment
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| :--- | :---------- | :--------- | :-------- | ------------------- | ---------------------- |
+| 14.1 | If the device is intended for use in combination with other devices or equipment the whole combination, including the connection system shall be safe and shall not impair the specified performance of the devices. Any restrictions on use applying to such combinations shall be indicated on the label and/or in the instructions for use. Connections which the user has to handle, such as fluid, gas transfer, electrical or mechanical coupling, shall be designed and constructed in such a way as to minimise all possible risks, such as misconnection. | No | Software device |  |  |
+| 14.2 | Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible: | No | Software device |
+| (a) | the risk of injury, in connection with their physical features, including the volume/pressure ratio, dimensional and where appropriate ergonomic features; | No | Software device |  |  |
+| (b) | risks connected with reasonably foreseeable external influences or environmental conditions, such as magnetic fields, external electrical and electromagnetic effects, electrostatic discharge, radiation associated with diagnostic or therapeutic procedures, pressure, humidity, temperature, variations in pressure and acceleration or radio signal interferences; | Yes | Software device | IEC 62366-1:2015 + COR1:2016 | Risk Table<br>Usability Evaluation Report |
+| (c) | the risks associated with the use of the device when it comes into contact with materials, liquids, and substances, including gases, to which it is exposed during normal conditions of use; | No | Software device |  |  |
+| (d) | the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts; | Yes | ISO 14971:2919 |  | Risk Table |
+| (e) | the risks of accidental ingress of substances into the device; | No | Software device |  |  |
+| (f) | the risks of reciprocal interference with other devices normally used in the investigations or for the treatment given; and | No | Software device |  |  |
+| (g) | risks arising where maintenance or calibration are not possible (as with implants), from ageing of materials used or loss of accuracy of any measuring or control mechanism. | No | Software device |  |  |
+| 14.3 | Devices shall be designed and manufactured in such a way as to minimize the risks of fire or explosion during normal use and in single fault condition. Particular attention shall be paid to devices the intended use of which includes exposure to or use in association with flammable or explosive substances or substances which could cause combustion. | No | Software device |  |  |
+| 14.4 | Devices shall be designed and manufactured in such a way that adjustment, calibration, and maintenance can be done safely and effectively. | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Development and Maintenance Plan |
+| 14.5 | Devices that are intended to be operated together with other devices or products shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and safe. | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Requirements List |
+| 14.6 | Any measurement, monitoring or display scale shall be designed and manufactured in line with ergonomic principles, taking account of the intended purpose, users and the environmental conditions in which the devices are intended to be used. | No | No measuring function |  |  |
+| 14.7 | Devices shall be designed and manufactured in such a way as to facilitate their safe disposal and the safe disposal of related waste substances by the user, patient or other person. To that end, manufacturers shall identify and test procedures and measures as a result of which their devices can be safely disposed after use. Such procedures shall be described in the instructions for use. | No | Software device |  |  |
+
+### 2.6) Devices with a Diagnostic or Measurement Function
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 15.1 | Diagnostic devices and devices with a measuring function, shall be designed and manufactured in such a way as to provide sufficient accuracy, precision and stability for their intended purpose, based on appropriate scientific and technical methods. The limits of accuracy shall be indicated by the manufacturer. | No | No measuring function |  |  |
+| 15.2 | The measurements made by devices with a measuring function shall be expressed in legal units conforming to the provisions of Council Directive 80/181/EEC (4). | No | No measuring function |  |  |
+
+### 2.7) Protection Against Radiation
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 16.1 | General |  |  |  |  |
+| (a) | Devices shall be designed, manufactured and packaged in such a way that exposure of patients, users and other persons to radiation is reduced as far as possible, and in a manner that is compatible with the intended purpose, whilst not restricting the application of appropriate specified levels for therapeutic and diagnostic purposes. | No | No radiation |  |  |
+| (b) | The operating instructions for devices emitting hazardous or potentially hazardous radiation shall contain detailed information as to the nature of the emitted radiation, the means of protecting the patient and the user, and on ways of avoiding misuse and of reducing the risks inherent to installation as far as possible and appropriate. Information regarding the acceptance and performance testing, the acceptance criteria, and the maintenance procedure shall also be specified. | No | No radiation |  |  |
+| 16.2 | Intended radiation |  |  |  |  |
+| (a) | Where devices are designed to emit hazardous, or potentially hazardous, levels of ionizing and/or non-ionizing radiation necessary for a specific medical purpose the benefit of which is considered to outweigh the risks inherent to the emission, it shall be possible for the user to control the emissions. Such devices shall be designed and manufactured to ensure reproducibility of relevant variable parameters within an acceptable tolerance. | No | No radiation |  |  |
+| (b) | Where devices are intended to emit hazardous, or potentially hazardous, ionizing and/or non-ionizing radiation, they shall be fitted, where possible, with visual displays and/or audible warnings of such emissions. | No | No radiation |  |  |
+| 16.3 | Devices shall be designed and manufactured in such a way that exposure of patients, users and other persons to the emission of unintended, stray or scattered radiation is reduced as far as possible. Where possible and appropriate, methods shall be selected which reduce the exposure to radiation of patients, users and other persons who may be affected. | No | No radiation |  |  |
+| 16.4 | Ionizing radiation |  |  |  |  |
+| (a) | Devices intended to emit ionizing radiation shall be designed and manufactured taking into account the requirements of the Directive 2013/59/Euratom laying down basic safety standards for protection against the dangers arising from exposure to ionizing radiation. | No | No radiation |  |  |
+| (b) | Devices intended to emit ionizing radiation shall be designed and manufactured in such a way as to ensure that, where possible, taking into account the intended use, the quantity, geometry and quality of the radiation emitted can be varied and controlled, and, if possible, monitored during treatment. | No | No radiation |  |  |
+| (c) | Devices emitting ionizing radiation intended for diagnostic radiology shall be designed and manufactured in such a way as to achieve an image and/or output quality that are appropriate to the intended medical purpose whilst minimizing radiation exposure of the patient and user. | No | No radiation |  |  |
+| (d) | Devices that emit ionizing radiation and are intended for therapeutic radiology shall be designed and manufactured in such a way as to enable reliable monitoring and control of the delivered dose, the beam type, energy and, where appropriate, the quality of radiation. | No | No radiation |  |  |
+
+### 2.8) Devices that Incorporate Electronic Programmable Systems and Softwares that are Devices Themselves
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 17.1 | Devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance. | Yes |  | IEC 62304:2006 / AMD1:2015 | Intended Use<br>SOP Integrated Software Development<br>SOP Change Management |
+| 17.2 | For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation. | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Development and Maintenance Plan<br>Clinical Evaluation Report |
+| 17.3 | Software referred to in this Section that is intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise). | Yes |  | IEC 62304:2006 / AMD1:2015 | SOP Integrated Software Development<br>Software Requirements List |
+| 17.4 | Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended. | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual<br>Software Requirements List |
+
+### 2.9) Active Devices and Devices Connected to Them
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 18.1 | For non-implantable active devices, in the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks. | Yes |  | ISO 14971:2019 | Risk Table |
+| 18.2 | Devices where the safety of the patient depends on an internal power supply shall be equipped with a means of determining the state of the power supply and an appropriate warning or indication for when the capacity of the power supply becomes critical. If necessary, such warning or indication shall be given prior to the power supply becoming critical. | No | Safety does not depend on power supply |  |  |
+| 18.3 | Devices where the safety of the patient depends on an external power supply shall include an alarm system to signal any power failure. | No | Safety does not depend on power supply |  |  |
+| 18.4 | Devices intended to monitor one or more clinical parameters of a patient shall be equipped with appropriate alarm systems to alert the user of situations which could lead to death or severe deterioration of the patient's state of health. | No | No monitoring of clinical parameters |  |  |
+| 18.5 | Devices shall be designed and manufactured in such a way as to reduce as far as possible the risks of creating electromagnetic interference which could impair the operation of the device in question or other devices or equipment in the intended environment. | No | Software device |  |  |
+| 18.6 | Devices shall be designed and manufactured in such a way as to provide a level of intrinsic immunity to electromagnetic interference such that is adequate to enable them to operate as intended. | No | Software device |  |  |
+| 18.7 | Devices shall be designed and manufactured in such a way as to avoid, as far as possible, the risk of accidental electric shocks to the patient, user or any other person, both during normal use of the device and in the event of a single fault condition in the device, provided the device is installed and maintained as indicated by the manufacturer. | No | Software device |  |  |
+| 18.8 | Devices shall be designed and manufactured in such a way as to protect, as far as possible, against unauthorized access that could hamper the device from functioning as intended. | Yes |  | ISO 14971:2019 | Technical and Organizational Measures<br>Software Requirements List |
+
+### 2.10) Particular requirements for active implantable devices
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 19.1 | Active implantable devices shall be designed and manufactured in such a way as to remove or minimize as far as possible: | No | Software device |  |  |
+| (a) | risks connected with the use of energy sources with particular reference, where electricity is used, to insulation, leakage currents and overheating of the devices, | No | Software device |  |  |
+| (b) | risks connected with medical treatment, in particular those resulting from the use of defibrillators or high-frequency surgical equipment, and | No | Software device |  |  |
+| (c) | risks which may arise where maintenance and calibration are impossible, including:— excessive increase of leakage currents,— ageing of the materials used, — excess heat generated by the device, — decreased accuracy of any measuring or control mechanism. | No | Software device |  |  |
+| 19.2 | Active implantable devices shall be designed and manufactured in such a way as to ensure — if applicable, the compatibility of the devices with the substances they are intended to administer, and — the reliability of the source of energy. | No | Software device |  |  |
+| 19.3 | Active implantable devices and, if appropriate, their component parts shall be identifiable to allow any necessary measure to be taken following the discovery of a potential risk in connection with the devices or their component parts. | No | Software device |  |  |
+| 19.4 | Active implantable devices shall bear a code by which they and their manufacturer can be unequivocally identified (particularly with regard to the type of device and its year of manufacture); it shall be possible to read this code, if necessary, without the need for a surgical operation. | No | Software device |  |  |
+
+### 2.11) Protection Against Mechanical and Thermal Risks
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 20.1 | Devices shall be designed and manufactured in such a way as to protect patients and users against mechanical risks connected with, for example, resistance to movement, instability and moving parts. | No | Software device |  |  |
+| 20.2 | Devices shall be designed and manufactured in such a way as to reduce to the lowest possible level the risks arising from vibration generated by the devices, taking account of technical progress and of the means available for limiting vibrations, particularly at source, unless the vibrations are part of the specified performance. | No | Software device |  |  |
+| 20.3 | Devices shall be designed and manufactured in such a way as to reduce to the lowest possible level the risks arising from the noise emitted, taking account of technical progress and of the means available to reduce noise, particularly at source, unless the noise emitted is part of the specified performance. | No | Software device |  |  |
+| 20.4 | Terminals and connectors to the electricity, gas or hydraulic and pneumatic energy supplies which the user or other person has to handle, shall be designed and constructed in such a way as to minimise all possible risks. | No | Software device |  |  |
+| 20.5 | Errors likely to be made when fitting or refitting certain parts which could be a source of risk shall be made impossible by the design and construction of such parts or, failing this, by information given on the parts themselves and/or their housings. The same information shall be given on moving parts and/or their housings where the direction of movement needs to be known in order to avoid risk. | No | Software device |  |  |
+| 20.6 | Accessible parts of devices (excluding the parts or areas intended to supply heat or reach given temperatures) and their surroundings shall not attain potentially dangerous temperatures under normal conditions of use. | No | Software device |  |  |
+
+### 2.12) Protection against the risks posed to the patient or user by devices supplying energy or substances
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 21.1 | Devices for supplying the patient with energy or substances shall be designed and constructed in such a way that the amount to be delivered can be set and maintained accurately enough to ensure the safety of the patient and of the user. | No | Software device |  |  |
+| 21.2 | Devices shall be fitted with the means of preventing and/or indicating any inadequacies in the amount of energy delivered or substances delivered which could pose a danger. Devices shall incorporate suitable means to prevent, as far as possible, the accidental release of dangerous levels of energy or substances from an energy and/or substance source. | No | Software device |  |  |
+| 21.3 | The function of the controls and indicators shall be clearly specified on the devices. Where a device bears instructions required for its operation or indicates operating or adjustment parameters by means of a visual system, such information shall be understandable to the user and, as appropriate, the patient. | No | Software device |  |  |
+
+### 2.13) Protection against the risks by medical devices intended by manufacturers for use by lay persons
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 22.1 | Devices for use by lay persons shall be designed and manufactured in such a way that they perform appropriately for their intended purpose taking into account the skills and the means available to lay persons and the influence resulting from variation that can be reasonably anticipated in the lay person's technique and environment. The information and instructions provided by the manufacturer shall be easy for the lay person to understand and apply. | Yes |  | IEC 62366-1:2015 + AC:2015 | Intended Use<br>User Manual<br>Usability Evaluation Report |
+| 22.2 | Devices for use by lay persons shall be designed and manufactured in such a way as to: |  |  |  |  |
+|  | — ensure that the device can be used safely and accurately by the intended user at all stages of the procedure, if necessary after appropriate training and/or information, | Yes |  | IEC 62366-1:2015 + AC:2015 | Usability Evaluation Report<br>(Record of User Training) |
+|  | — reduce, as far as possible and appropriate, the risk from unintended cuts and pricks such as needle stick injuries, and | No | Software device |  |  |
+|  | — reduce as far as possible the risk of error by the intended user in the handling of the device and, if applicable, in the interpretation of the results. |  |  | IEC 62366-1:2015 + AC:2015 | Usability Evaluation Report |
+| 22.3 | Devices for use by lay persons shall, where appropriate, include a procedure by which the lay person: |  |  |  |  |
+|  | — can verify that, at the time of use, the device will perform as intended by the manufacturer, and | Yes |  | IEC 62366-1:2015 + AC:2015 | Stakeholder Requirements<br>Usability Evaluation Report |
+|  | — if applicable, is warned if the device has failed to provide a valid result. | Yes |  | IEC 62366-1:2015 + AC:2015 | Stakeholder Requirements<br>Usability Evaluation Report |
+
+## Chapter III: Requirements Regarding the Information Supplied with the Device
+
+### 3.1) Label and Instructions for Use
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| 23.1 | Each device shall be accompanied by the information needed to identify the device and its manufacturer, and by any safety and performance information relevant to the user, or any other person, as appropriate. Such information may appear on the device itself, on the packaging or in the instructions for use, and shall, if the manufacturer has a website, be made available and kept up to date on the website, taking into account the following: |  |  |  |
+| (a) | The medium, format, content, legibility, and location of the label and instructions for use shall be appropriate to the particular device, its intended purpose and the technical knowledge, experience, education or training of the intended user(s). In particular, instructions for use shall be written in terms readily understood by the intended user and, where appropriate, supplemented with drawings and diagrams. | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (b) | The information required on the label shall be provided on the device itself. If this is not practicable or appropriate, some or all of the information may appear on the packaging for each unit, and/or on the packaging of multiple devices. | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Requirements List<br>SOP Certification and Product Registration |
+| (c) | Labels shall be provided in a human-readable format and may be supplemented by machine-readable information, such as radio-frequency identification (‘RFID’) or bar codes. | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Requirements List<br>SOP Certification and Product Registration |
+| (d) | Instructions for use shall be provided together with devices. By way of exception, instructions for use shall not be required for class I and class IIa devices if such devices can be used safely without any such instructions and unless otherwise provided for elsewhere in this Section. | Yes |  | IEC 62304:2006 / AMD1:2015,<br>IEC 62366-1:2015 + AC:2015 | User Manual, Software Requirements List |
+| (e) | Where multiple devices are supplied to a single user and/or location, a single copy of the instructions for use may be provided if so agreed by the purchaser who in any case may request further copies to be provided free of charge. | Yes |  |  |  |
+| (f) | Instructions for use may be provided to the user in non-paper format (e.g. electronic) to the extent, and only under the conditions, set out in Regulation (EU) No 207/2012 or in any subsequent implementing rules adopted pursuant to this Regulation. | Yes |  | IEC 62304:2006 / AMD1:2015,<br>IEC 62366-1:2015 + AC:2015 | User Manual |
+| (g) | Residual risks which are required to be communicated to the user and/or other person shall be included as limitations, contra-indications, precautions or warnings in the information supplied by the manufacturer. | Yes |  | IEC 62304:2006 / AMD1:2015,<br>IEC 62366-1:2015 + AC:2015 | User Manual |
+| (h) | Where appropriate, the information supplied by the manufacturer shall take the form of internationally recognized symbols. Any symbol or identification colour used shall conform to the harmonised standards or CS. In areas for which no harmonised standards or CS exist, the symbols and colours shall be described in the documentation supplied with the device. | Yes |  | ISO 15223-1:2017 | User Manual |
+| 23.2 | The label shall bear all of the following particulars: |  |  |  |  |
+| (a) | the name or trade name of the device; | Yes |  |  | User Manual |
+| (b) | the details strictly necessary for a user to identify the device, the contents of the packaging and, where it is not obvious for the user, the intended purpose of the device; | Yes |  |  | User Manual |
+| (c) | the name, registered trade name or registered trade mark of the manufacturer and the address of its registered place of business; | Yes |  |  | User Manual |
+| (d) | if the manufacturer has its registered place of business outside the Union, the name of the authorized representative and address of the registered place of business of the authorized representative; | No | Based in EU |  |  |
+| (e) | where applicable, an indication that the device contains or incorporates: — a medicinal substance, including a human blood or plasma derivative, or — tissues or cells, or their derivatives, of human origin, or — tissues or cells of animal origin, or their derivatives, as referred to in Regulation (EU) No 722/2012; | No | Software device |  |  |
+| (f) | where applicable, information labelled in accordance with Section 10.4.5.; | No | Section is not applicable |  |  |
+| (g) | the lot number or the serial number of the device preceded by the words LOT NUMBER or SERIAL NUMBER or an equivalent symbol, as appropriate; | No | No batch production |  |  |
+| (h) | the UDI carrier referred to in Article 27(4) and Part C of Annex VII; | Yes |  | IEC 62304:2006 / AMD1:2015,<br>IEC 62366-1:2015 + AC:2015 | User Manual<br>SOP Certification and Product Registration |
+| (i) | an unambiguous indication of the time limit for using or implanting the device safely, expressed at least in terms of year and month, where this is relevant; | No | Software device |  |  |
+| (j) | where there is no indication of the date until when it may be used safely, the date of manufacture. This date of manufacture may be included as part of the lot number or serial number, provided the date is clearly identifiable; | Yes |  |  |  |
+| (k) | an indication of any special storage and/or handling condition that applies; | No | Software device |  |  |
+| (l) | if the device is supplied sterile, an indication of its sterile state and the sterilisation method; | No | Software device |  |
+| (m) | warnings or precautions to be taken that need to be brought to the immediate attention of the user of the device, and to any other person. This information may be kept to a minimum in which case more detailed information shall appear in the instructions for use, taking into account the intended users; | No | Not necessary based on risk file |  |  |
+| (n) | if the device is intended for single use, an indication of that fact. A manufacturer's indication of single use shall be consistent across the Union; | No | No single use device |  |  |
+| (o) | if the device is a single-use device that has been reprocessed, an indication of that fact, the number of reprocessing cycles already performed, and any limitation as regards the number of reprocessing cycles; | No | No single use device |  |  |
+| (p) | if the device is custom-made, the words ‘custom-made device’; | No | Not custom-made |  |  |
+| (q) | an indication that the device is a medical device. If the device is intended for clinical investigation only, the words ‘exclusively for clinical investigation’; | Yes |  |  |  |
+| (r) | in the case of devices that are composed of substances or of combinations of substances that are intended to be introduced into the human body via a body orifice or applied to the skin and that are absorbed by or locally dispersed in the human body, the overall qualitative composition of the device and quantitative information on the main constituent or constituents responsible for achieving the principal intended action; | No | Software device |  |  |
+| (s) | for active implantable devices, the serial number, and for other implantable devices, the serial number or the lot number. | No | Software device |  |  |
+| 23.3 | For packaging which maintains the sterile condition of a device (‘sterile packaging’), the following particulars shall appear on the sterile packaging: |  |  |  |  |
+| (a) | an indication permitting the sterile packaging to be recognized as such, | No | Software device |  |  |
+| (b) | a declaration that the device is in a sterile condition, | No | Software device |  |  |
+| (c) | the method of sterilization, | No | Software device |  |  |
+| (d) | the name and address of the manufacturer, | No | Software device |  |  |
+| (e) | a description of the device, | No | Software device |  |  |
+| (f) | if the device is intended for clinical investigations, the words ‘exclusively for clinical investigations’, | No | Software device |  |  |
+| (g) | if the device is custom-made, the words ‘custom-made device’, | No | Software device |  |  |
+| (h) | the month and year of manufacture, | No | Software device |  |  |
+| (i) | an unambiguous indication of the time limit for using or implanting the device safely expressed at least in terms of year and month, and | No | Software device |  |  |
+| (j) | an instruction to check the instructions for use for what to do if the sterile packaging is damaged or unintentionally opened before use. | No | Software device |  |  |
+| 23.4 | The instructions for use shall contain all of the following particulars: |  |  |  |  |
+| (a) | the particulars referred to in points (a), (c), (e), (f), (k), (l), (n) and (r) of Section 23.2; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (b) | the device's intended purpose with a clear specification of indications, contra-indications, the patient target group or groups, and of the intended users, as appropriate; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (c) | where applicable, a specification of the clinical benefits to be expected. | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (d) | where applicable, links to the summary of safety and clinical performance referred to in Article 32; | No | Software device |  |  |
+| (e) | the performance characteristics of the device; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (f) | where applicable, information allowing the healthcare professional to verify if the device is suitable and select the corresponding software and accessories; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (g) | any residual risks, contra-indications and any undesirable side-effects, including information to be conveyed to the patient in this regard; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (h) | specifications the user requires to use the device appropriately, e.g. if the device has a measuring function, the degree of accuracy claimed for it; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (i) | details of any preparatory treatment or handling of the device before it is ready for use or during its use, such as sterilization, final assembly, calibration, etc., including the levels of disinfection required to ensure patient safety and all available methods for achieving those levels of disinfection; | No | Software device |  |  |
+| (j) | any requirements for special facilities, or special training, or particular qualifications of the device user and/or other persons; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (k) | the information needed to verify whether the device is properly installed and is ready to perform safely and as intended by the manufacturer, together with, where relevant: — details of the nature, and frequency, of preventive and regular maintenance, and of any preparatory cleaning or disinfection, — identification of any consumable components and how to replace them,— information on any necessary calibration to ensure that the device operates properly and safely during its intended lifetime, and — methods for eliminating the risks encountered by persons involved in installing, calibrating or servicing devices; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (l) | if the device is supplied sterile, instructions in the event of the sterile packaging being damaged or unintentionally opened before use; | No | Software device |  |  |
+| (m) | if the device is supplied non-sterile with the intention that it is sterilized before use, the appropriate instructions for sterilization; | No | Software device |  |  |
+| (n) | if the device is reusable, information on the appropriate processes for allowing reuse, including cleaning, disinfection, packaging and, where appropriate, the validated method of re-sterilization appropriate to the Member State or Member States in which the device has been placed on the market. Information shall be provided to identify when the device should no longer be reused, e.g. signs of material degradation or the maximum number of allowable reuses; | No | Software device |  |  |
+| (o) | an indication, if appropriate, that a device can be reused only if it is reconditioned under the responsibility of the manufacturer to comply with the general safety and performance requirements; | No | No restrictions on reuse |  |  |
+| (p) | if the device bears an indication that it is for single use, information on known characteristics and technical factors known to the manufacturer that could pose a risk if the device were to be re-used. This information shall be based on a specific section of the manufacturer's risk management documentation, where such characteristics and technical factors shall be addressed in detail. If in accordance with point (d) of Section 23.1. no instructions for use are required, this information shall be made available to the user upon request; | No | No single-use device |  |  |
+| (q) | for devices intended for use together with other devices and/or general purpose equipment: — information to identify such devices or equipment, in order to obtain a safe combination, and/or — information on any known restrictions to combinations of devices and equipment; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (r) | if the device emits radiation for medical purposes: |  |  |  |  |
+|  | — detailed information as to the nature, type and where appropriate, the intensity and distribution of the emitted radiation, | No | Software device |  |  |
+|  | — the means of protecting the patient, user, or other person from unintended radiation during use of the device; | No | Software device |  |  |
+| (s) | information that allows the user and/or patient to be informed of any warnings, precautions, contra-indications, measures to be taken and limitations of use regarding the device. That information shall, where relevant, allow the user to brief the patient about any warnings, precautions, contra-indications, measures to be taken and limitations of use regarding the device. The information shall cover, where appropriate: | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+|  | — warnings, precautions and/or measures to be taken in the event of malfunction of the device or changes in its performance that may affect safety, | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+|  | — warnings, precautions and/or measures to be taken as regards the exposure to reasonably foreseeable external influences or environmental conditions, such as magnetic fields, external electrical and electromagnetic effects, electrostatic discharge, radiation associated with diagnostic or therapeutic procedures, pressure, humidity, or temperature, | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+|  | — warnings, precautions and/or measures to be taken as regards the risks of interference posed by the reasonably foreseeable presence of the device during specific diagnostic investigations, evaluations, or therapeutic treatment or other procedures such as electromagnetic interference emitted by the device affecting other equipment, | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+|  | — if the device is intended to administer medicinal products, tissues or cells of human or animal origin, or their derivatives, or biological substances, any limitations or incompatibility in the choice of substances to be delivered, | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+|  | — warnings, precautions and/or limitations related to the medicinal substance or biological material that is incorporated into the device as an integral part of the device; and | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+|  | — precautions related to materials incorporated into the device that contain or consist of CMR substances or endocrine-disrupting substances, or that could result in sensitisation or an allergic reaction by the patient or user; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (t) | in the case of devices that are composed of substances or of combinations of substances that are intended to be introduced into the human body and that are absorbed by or locally dispersed in the human body, warnings and precautions, where appropriate, related to the general profile of interaction of the device and its products of metabolism with other devices, medicinal products and other substances as well as contra-indications, undesirable side-effects and risks relating to overdose; | No | Software device |  |  |
+| (u) | in the case of implantable devices, the overall qualitative and quantitative information on the materials and substances to which patients can be exposed; | No | Software device |  |  |
+| (v) | warnings or precautions to be taken in order to facilitate the safe disposal of the device, its accessories and the consumables used with it, if any. This information shall cover, where appropriate: | No | Not required based on risk file |  |  |
+|  | — infection or microbial hazards such as explants, needles or surgical equipment contaminated with potentially infectious substances of human origin, and | No | Software device |  |  |
+|  | — physical hazards such as from sharps. | No | Software device |  |  |
+|  | If in accordance with the point (d) of Section 23.1 no instructions for use are required, this information shall be made available to the user upon request; | No | IFU exist |  |  |
+| (w) | for devices intended for use by lay persons, the circumstances in which the user should consult a healthcare professional; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (x) | for the devices covered by this Regulation pursuant to Article 1(2), information regarding the absence of a clinical benefit and the risks related to use of the device; | No | Clinical benefit exists |  |  |
+| (y) | date of issue of the instructions for use or, if they have been revised, date of issue and identifier of the latest revision of the instructions for use; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (z) | a notice to the user and/or patient that any serious incident that has occurred in relation to the device should be reported to the manufacturer and the competent authority of the Member State in which the user and/or patient is established; | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+| (aa) | information to be supplied to the patient with an implanted device in accordance with Article 18; | No | Software device |  |  |
+| (ab) | for devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended. | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+
+## Annex II: Technical Documentation
+
+The technical documentation and, if applicable, the summary thereof to be drawn up by the manufacturer shall be presented in a clear, organized, readily searchable and unambiguous manner and shall include in particular the elements listed in this Annex.
+
+### 4.1.1) Device Description and Specification
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| (a) | product or trade name and a general description of the device including its intended purpose and intended users; | Yes |  | IEC 62304:2006 / AMD1:2015 | Intended Use |
+| (b) | the Basic UDI-DI as referred to in Part C of Annex VI assigned by the manufacturer to the device in question, as soon as identification of this device becomes based on a UDI system, or otherwise a clear identification by means of product code, catalogue number or other unambiguous reference allowing traceability; | Yes |  | IEC 62304:2006 / AMD1:2015 | UDI Label<br>SOP Certification and Product Registration |
+| (c) | the intended patient population and medical conditions to be diagnosed, treated and/or monitored and other considerations such as patient selection criteria, indications, contra-indications, warnings; | Yes |  | IEC 62304:2006 / AMD1:2015 | Intended Use |
+| (d) | principles of operation of the device and its mode of action, scientifically demonstrated if necessary; | Yes |  | IEC 62304:2006 / AMD1:2015 | Intended Use |
+| (e) | the rationale for the qualification of the product as a device; | Yes |  | IEC 62304:2006 / AMD1:2015 | Medical Device Classification |
+| (f) | the risk class of the device and the justification for the classification rule(s) applied in accordance with Annex VIII; | Yes |  | IEC 62304:2006 / AMD1:2015 | Medical Device Classification |
+| (g) | an explanation of any novel features; | Yes |  | IEC 62304:2006 / AMD1:2015 | Intended Use |
+| (h) | a description of the accessories for a device, other devices and other products that are not devices, which are intended to be used in combination with it; | No | No device accessories |  |  |
+| (i) | a description or complete list of the various configurations/variants of the device that are intended to be made available on the market; | Yes |  | IEC 62304:2006 / AMD1:2015 | Medical Devices List |
+| (j) | a general description of the key functional elements, e.g. its parts/components (including software if appropriate), its formulation, its composition, its functionality and, where relevant, its qualitative and quantitative composition. Where appropriate, this shall include labelled pictorial representations (e.g. diagrams, photographs, and drawings), clearly indicating key parts/components, including sufficient explanation to understand the drawings and diagrams; | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Development and Maintenance Plan<br>Software Requirements List |
+| (k) | a description of the raw materials incorporated into key functional elements and those making either direct contact with the human body or indirect contact with the body, e.g., during extracorporeal circulation of body fluids; | No | Software device |  |  |
+| (l) | technical specifications, such as features, dimensions and performance attributes, of the device and any variants/configurations and accessories that would typically appear in the product specification made available to the user, for example in brochures, catalogues and similar publications. | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Requirements List<br>Marketing Material |
+
+### 4.1.2) References to Previous and Similar Generations of the Device
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| (a) | an overview of the previous generation or generations of the device produced by the manufacturer, where such devices exist; | Yes |  | ISO 13485:2016 | Medical Devices List |
+| (b) | an overview of identified similar devices available on the Union or international markets, where such devices exist. | Yes |  | ISO 13485:2016 | Medical Devices List<br>Clinical Evaluation Report |
+
+### 4.2) Information to be Supplied by the Manufacturer
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+|  | A complete set of |  |  |  |  |
+| (a) | — the label or labels on the device and on its packaging, such as single unit packaging, sales packaging, transport packaging in case of specific management conditions, in the languages accepted in the Member States where the device is envisaged to be sold; and | Yes |  | ISO 13485:2016,<br>IEC 62304:2006 / AMD1:2015 | UDI Label<br>User Manual |
+| (b) | — the instructions for use in the languages accepted in the Member States where the device is envisaged to be sold. | Yes |  | IEC 62304:2006 / AMD1:2015 | User Manual |
+
+### 4.3) Design and Manufacturing Information
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| (a) | information to allow the design stages applied to the device to be understood; | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Development and Maintenance Plan |
+| (b) | complete information and specifications, including the manufacturing processes and their validation, their adjuvants, the continuous monitoring and the final product testing. Data shall be fully included in the technical documentation; | Yes |  | ISO 13485:2016,<br>IEC 62304:2006 / AMD1:2015 | SOP Integrated Software Development<br>Software Requirements List<br>System Test Report |
+| (c) | identification of all sites, including suppliers and sub-contractors, where design and manufacturing activities are performed. | Yes |  | ISO 13485:2016,<br>IEC 62304:2006 / AMD1:2015 | Quality Management Manual<br>List of Qualified Suppliers |
+
+### 4.4) General Safety and Performance Requirements
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+|  | The documentation shall contain information for the demonstration of conformity with the general safety and performance requirements set out in Annex I that are applicable to the device taking into account its intended purpose, and shall include a justification, validation and verification of the solutions adopted to meet those requirements. The demonstration of conformity shall include: | Yes |  |  | MDR General Safety and Performance Requirements Checklist |
+| (a) | the general safety and performance requirements that apply to the device and an explanation as to why others do not apply; | Yes |  |  | MDR General Safety and Performance Requirements Checklist |
+| (b) | the method or methods used to demonstrate conformity with each applicable general safety and performance requirement; | Yes |  |  | MDR General Safety and Performance Requirements Checklist |
+| (c) | the harmonized standards, CS or other solutions applied; and | Yes |  |  | MDR General Safety and Performance Requirements Checklist |
+| (d) | the precise identity of the controlled documents offering evidence of conformity with each harmonized standard, CS or other method applied to demonstrate conformity with the general safety and performance requirements. The information referred to under this point shall incorporate a cross-reference to the location of such evidence within the full technical documentation and, if applicable, the summary technical documentation. | Yes |  |  | MDR General Safety and Performance Requirements Checklist |
+
+### 4.5) Benefit-Risk-Analysis and Risk Management
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+|  | The documentation shall contain information on: |  |  |  |  |
+| (a) | the benefit-risk analysis referred to in Sections 1 and 8 of Annex I, and | Yes |  | ISO 13485:2016 | Clinical Evaluation Report |
+| (b) | the solutions adopted and the results of the risk management referred to in Section 3 of Annex I. | Yes |  | ISO 13485:2016,<br>ISO 14971:2019 | Risk Table<br>Risk Management Report |
+
+### 4.6) Product Verification and Validation
+
+The documentation shall contain the results and critical analyses of all verifications and validation tests and/or studies undertaken to demonstrate conformity of the device with the requirements of this Regulation and in particular the applicable general safety and performance requirements.
+
+#### 4.6.1) Pre-Clinical and Clinical Data
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| (a) | results of tests, such as engineering, laboratory, simulated use and animal tests, and evaluation of published literature applicable to the device, taking into account its intended purpose, or to similar devices, regarding the pre-clinical safety of the device and its conformity with the specifications; | Yes |  | ISO 13485:2016 | Clinical Evaluation Report |
+| (b) | detailed information regarding test design, complete test or study protocols, methods of data analysis, in addition to data summaries and test conclusions regarding in particular: |  |  |  |  |
+|  | — the biocompatibility of the device including the identification of all materials in direct or indirect contact with the patient or user; | No | Software device |  |  |
+|  | — physical, chemical and microbiological characterization; | No | Software device |  |  |
+|  | — electrical safety and electromagnetic compatibility; | No | Software device |  |  |
+|  | — software verification and validation (describing the software design and development process and evidence of the validation of the software, as used in the finished device. This information shall typically include the summary results of all verification, validation and testing performed both in-house and in a simulated or actual user environment prior to final release. It shall also address all of the different hardware configurations and, where applicable, operating systems identified in the information supplied by the manufacturer); | Yes |  | IEC 62304:2006 / AMD1:2015 | Software Requirements List<br>System Test Report<br>Usability Evaluation Report |
+|  | — stability, including shelf life; and | No | Software device |  |  |
+|  | — performance and safety. | Yes |  | ISO 13485:2016,<br>ISO 14971:219,<br>IEC 62304:2006 / AMD1:2015 | Risk Management Report<br>Clinical Evaluation Report |
+|  | Where applicable, conformity with the provisions of Directive 2004/10/EC of the European Parliament and of the Council (1) shall be demonstrated. Where no new testing has been undertaken, the documentation shall incorporate a rationale for that decision. An example of such a rationale would be that biocompatibility testing on identical materials was conducted when those materials were incorporated in a previous version of the device that has been legally placed on the market or put into service; | No | Software device |  |  |
+| (c) | the clinical evaluation report and its updates and the clinical evaluation plan referred to in Article 61(12) and Part A of Annex XIV; | Yes |  | ISO 13485:2016 | Clinical Evaluation Plan<br>Clinical Evaluation Report |
+| (d) | the PMCF plan and PMCF evaluation report referred to in Part B of Annex XIV or a justification why a PMCF is not applicable. | Yes |  | ISO 13485:2016 | Post-Market Clinical Follow-Up Plan and Report |
+
+#### 4.6.2) Additional Information Required in Specific Cases
+
+| **No.** | **Requirement** | **Applicable** | **Rationale** | **Applicable Standard** | **Evidence of Conformity** |
+| --- | ----------- | ---------- | --------- | ------------------- | ---------------------- |
+| (a) | Where a device incorporates, as an integral part, a substance which, if used separately, may be considered to be a medicinal product within the meaning of point 2 of Article 1 of Directive 2001/83/EC, including a medicinal product derived from human blood or human plasma, as referred to in the first subparagraph of Article 1(8), a statement indicating this fact. In this case, the documentation shall identify the source of that substance and contain the data of the tests conducted to assess its safety, quality and usefulness, taking account of the intended purpose of the device. | No | Software device |  |  |
+| (b) | Where a device is manufactured utilising tissues or cells of human or animal origin, or their derivatives, and is covered by this Regulation in accordance with points (f) and (g) of Article 1(6, and where a device incorporates, as an integral part, tissues or cells of human origin or their derivatives that have an action ancillary to that of the device and is covered by this Regulation in accordance with the first subparagraph of Article 1(10), a statement indicating this fact. In such a case, the documentation shall identify all materials of human or animal origin used and provide detailed information concerning the conformity with Sections 13.1. or 13.2., respectively, of Annex I. | No | Software device |  |  |
+| (c) | In the case of devices that are composed of substances or combinations of substances that are intended to be introduced into the human body and that are absorbed by or locally dispersed in the human body, detailed information, including test design, complete test or study protocols, methods of data analysis, and data summaries and test conclusions, regarding studies in relation to: | No | Software device |  |  |
+|  | — absorption, distribution, metabolism and excretion; | No | Software device |  |  |
+|  | — possible interactions of those substances, or of their products of metabolism in the human body, with other devices, medicinal products or other substances, considering the target population, and its associated medical conditions; | No | Software device |  |  |
+|  | — local tolerance; and | No | Software device |  |  |
+|  | — toxicity, including single-dose toxicity, repeat-dose toxicity, genotoxicity, carcinogenicity and reproductive and developmental toxicity, as applicable depending on the level and nature of exposure to the device. | No | Software device |  |  |
+|  | In the absence of such studies, a justification shall be provided. | No | Software device |  |  |
+| (d) | In the case of devices containing CMR or endocrine-disrupting substances referred to in Section 10.4.1 of Annex I, the justification referred to in Section 10.4.2 of that Annex. | No | Software device |  |  |
+| (e) | In the case of devices placed on the market in a sterile or defined microbiological condition, a description of the environmental conditions for the relevant manufacturing steps. In the case of devices placed on the market in a sterile condition, a description of the methods used, including the validation reports, with respect to packaging, sterilization and maintenance of sterility. The validation report shall address bioburden testing, pyrogen testing and, if applicable, testing for sterilant residues. | No | Software device |  |  |
+| (f) | In the case of devices placed on the market with a measuring function, a description of the methods used in order to ensure the accuracy as given in the specifications. | No | No measuring function |  |  |
+| (g) | If the device is to be connected to other device(s) in order to operate as intended, a description of this combination/configuration including proof that it conforms to the general safety and performance requirements when connected to any such device(s) having regard to the characteristics specified by the manufacturer. | No | Standalone software device |  |  |
diff --git a/openregulatory/templates/general/declaration-of-conformity-mdd-class-i.md b/openregulatory/templates/general/declaration-of-conformity-mdd-class-i.md
new file mode 100644
index 00000000..9dceb933
--- /dev/null
+++ b/openregulatory/templates/general/declaration-of-conformity-mdd-class-i.md
@@ -0,0 +1,45 @@
+# EC Declaration of Conformity
+
+## Manufacturer
+
+**\<Company Name\>**
+
+*\<Company Address\>*
+
+## Medical Device
+
+**\<Name of Device\>**
+
+*\<Version of Device\>*
+
+*\<Basic UDI-DI, if applicable\>*
+
+## Classification
+
+**Medical Device Class: I**
+
+Classification based on appendix IX, section 3, rule 12 of the Directive 93/42/EEC.
+
+## Conformity Assessment
+
+Conformity assessment procedure: Appendix VII of the Directive 93/42/EEC.
+
+The Medical Device referenced above meets the provisions of the Directive 93/42/EEC for Medical Devices.
+
+> The actual nitty-gritty proof that you're meeting the provisions is fulfilled by going through the essential
+> requirements of the MDD and documenting that.
+
+> This document needs to be signed in some way. If you're using software which supports electronic signatures,
+> use it to sign this document. Otherwise, print it out, sign it old-school, scan it and upload it to your QMS
+> folder.
+
+Expiration Date: 27.05.2024
+
+> This date only applies to MDD legacy devices under MDR. For MDR class I devices, this can be left out or
+> filled out "undated".
+
+<br/>
+
+---
+
+Place, Date, Signature of CEO
diff --git a/openregulatory/templates/general/essential-requirements-mdd.md b/openregulatory/templates/general/essential-requirements-mdd.md
new file mode 100644
index 00000000..ea5d6ad7
--- /dev/null
+++ b/openregulatory/templates/general/essential-requirements-mdd.md
@@ -0,0 +1,184 @@
+# Essential Requirements MDD (93/42/EEC)
+
+> This document goes through all essential requirements as listed in Annex I of the MDD. Please don't get
+> confused: Contrary to all other templates here, quoted regions below (like this one) don't contain
+> explanations (like this one), but instead actually quote the relevant section of the MDD. So, the legalese
+> below is not me explaining stuff to you - it's the MDD.
+>
+> Underneath each requirement, you determine whether it's applicable to your product. I've pre-filled it,
+> making a few assumptions for software. But you should definitely go through all of them, just to make sure,
+> e.g., 10 (do you have a measuring function?) and 12.4 (are you monitoring clinical parameters of
+> patients?). Good luck.
+
+## 1
+
+> The devices must be designed and manufactured in such a way that, when used under the conditions and for the
+> purposes intended, they will not compromise the clinical condition or the safety of patients, or the safety
+> and health of users or, where applicable, other persons, provided that any risks which may be associated with
+> their intended use constitute acceptable risks when weighed against the benefits to the patient and are
+> compatible with a high level of protection of health and safety.
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** ISO 14971:2019 (Risk Management Report), Clinical Evaluation
+
+> This shall include reducing, as far as possible, the risk of use error due to the ergonomic features of the
+> device and the environment in which the device is intended to be used (design for patient safety)
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** ISO 14971:2019 (Risk Management Report), IEC 62366-1:2015 (Usability Evaluation
+   Report)
+
+> and consideration of the technical knowledge, experience, education and training and where applicable the
+> medical and physical conditions of intended users (design for lay, professional, disabled or other users).
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** IEC 62366-1:2015 (Usability Evaluation Report)
+
+## 2
+
+> The solutions adopted by the manufacturer for the design and construction of the devices must conform to
+> safety principles, taking account of the generally acknowledged state of the art.
+>
+> In selecting the most appropriate solutions, the manufacturer must apply the following principles in the
+> following order:
+>
+>  * Eliminate or reduce risks as far as possible (inherently safe design and construction),
+>  * Where appropriate take adequate protection measures including alarms if necessary, in relation to risks
+>    that cannot be eliminated,
+>  * Inform users of the residual risks due to any shortcomings of the protection measures adopted.
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** ISO 14971:2019 (Risk Management Report)
+
+## 3
+
+> The devices must achieve the performances intended by the manufacturer and be designed, manufactured and
+> packaged in such a way that they are suitable for one or more of the functions referred to in Article 1 (2)
+> (a), as specified by the manufacturer.
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** IEC 62304:2006 (Software Verification), Clinical Evaluation
+
+## 4
+
+> The characteristics and performances referred to in Sections 1, 2 and 3 must not be adversely affected to
+> such a degree that the clinical conditions and safety of the patients and, where applicable, of other
+> persons are compromised during the lifetime of the device as indicated by the manufacturer, when the device
+> is subjected to the stresses which can occur during normal conditions of use.
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** ISO 14971:2019 (Risk Management Report), IEC 62304:2006 (Software Verification
+   & Validation)
+
+## 5
+
+> The devices must be designed, manufactured and packed in such a way that their characteristics and
+> performances during their intended use will not be adversely affected during transport and storage taking
+> account of the instructions and information provided by the manufacturer.
+
+ * **Applicable:** No
+
+## 6
+
+> Any undesirable side-effect must constitute an acceptable risk when weighed against the performances
+> intended.
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** ISO 14971:2019 (Risk Management Report)
+
+## 6a
+
+> Demonstration of conformity with the essential requirements must include a clinical evaluation in accordance
+> with Annex X.
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** Clinical Evaluation
+
+## 7: Chemical, physical and biological properties
+
+* **Applicable:** No
+
+## 8: Infection and microbial contamination
+
+* **Applicable:** No
+
+## 9.1
+
+> If the device is intended for use in combination with other devices or equipment, the whole combination,
+> including the connection system must be safe and must not impair the specified performances of the
+> devices. Any restrictions on use must be indicated on the label or in the instructions for use.
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** ISO 14971:2019 (Risk Management Report)
+
+## 9.2
+
+> Devices must be designed and manufactured in such a way as to remove or minimize as far as possible:
+>
+>  * The risk of injury, in connection with their physical features, including the volume/pressure ratio,
+>    dimensional and where appro- priate ergonomic features,
+>  * The risks connected with reasonably foreseeable environmental conditions, such as magnetic fields, external
+>    electrical influences, electrostatic discharge, pressure, temperature or variations in pressure and
+>    acceleration,
+>  * The risks of reciprocal interference with other devices normally used in the investigations or for the
+>    treatment given,
+>  * The risks arising where maintenance or calibration are not possible (as with implants), from ageing of
+>    materials used or loss of accuracy of any measuring or control mechanism.
+
+ * **Applicable:** No
+
+## 9.3
+
+> Devices must be designed and manufactured in such a way as to minimize the risks of fire or explosion during
+> normal use and in a single fault condition. Particular attention must be paid to devices whose intended use
+> includes exposure to flammable substances or to substances which could cause combustion.
+
+ * **Applicable:** No
+
+## 10: Devices with a measuring function
+
+ * **Applicable:** No
+
+## 11: Protection against radiation
+
+ * **Applicable:** No
+
+## 12.1
+
+> Devices incorporating electronic programmable systems must be designed to ensure the repeatability,
+> reliability and performance of these systems according to the intended use. In the event of a single fault
+> condition (in the system) appropriate means should be adopted to eliminate or reduce as far as possible
+> consequent risks.
+
+ * **Applicable:** Yes
+
+## 12.1a
+
+> For devices which incorporate software or which are medical software in themselves, the software must be
+> validated according to the state of the art taking into account the principles of development lifecycle,
+> risk management, validation and verification.
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** ISO 14971:2019 (Risk Management Report), IEC 62304:2006 (SOP Software
+   Development, Software Verification & Validation), IEC 62366-1:2015 (Usability Evaluation Report)
+
+## 12.2 - 12.3
+
+ * **Applicable:** No
+
+## 12.4
+
+> Devices intended to monitor one or more clinical parameters of a patient must be equipped with appropriate
+> alarm systems to alert the user of situations which could lead to death or severe deterioration of the
+> patient's state of health.
+
+ * **Applicable:** No (no monitoring)
+
+## 12.5 - 12.8
+
+ * **Applicable:** No
+
+## 13 Information supplied by the manufacturer
+
+ * **Applicable:** Yes
+ * **Evidence of Conformity:** ISO 14971:2019, IEC 62366-1:2015 (Labelling, Instructions for Use)
diff --git a/openregulatory/templates/general/instructions-for-use.md b/openregulatory/templates/general/instructions-for-use.md
new file mode 100644
index 00000000..6d0fb251
--- /dev/null
+++ b/openregulatory/templates/general/instructions-for-use.md
@@ -0,0 +1,116 @@
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 4.2.3                  | (All)            |
+
+# User Manual [enter Product Name]
+
+Version: [enter content]
+Date: [enter content]
+
+
+[Placeholder Company Address]
+Email: [enter content]
+Website: [enter content]
+
+[Placeholder CE Sign]
+[Placeholder UDI]
+
+[enter Product Name]   is a class [enter content] medical device in accordance with 93/42/EEC (for MDD) // Regulation (EU) 2017/745 (for MDR).
+UMDNS Code: [enter content]
+
+Symbols:
+
+Safety Information:
+[Placeholder Symbol]
+This symbol indicates important safety-related information.
+
+Additional Information:
+[Placeholder Symbol]
+This symbol indicates supplementary information.
+
+> On your introductory pages, explain the symbols that you use in the following sections. Take into account standards like ISO 15223.
+
+> **General Provisions:** Instructions for use are regulated in Section 13 of the Essential Requirements (MDD) and Chapter 3, Section 23 of the General Safety and Performance Requirements (MDR). You may be able to make a case for why your users must not be provided with instructions for use, based on the exception stated in Section 13.1 (MDD) or Section 23.1.d (MDR):
+> 
+> "By way of exception, no such instructions for use are needed for devices in Class I or IIa if they can be used safely without any such instructions."
+> 
+> **Language Requirements:** Language requirements are regulated on the national level. German Medical Device Law (Medizinprodukte-Durchführungsgesetz (MPDG), Art. 8) typically requires German, but also gives leeway to argue that English may be a language that is easily understood by your users if those are trained professionals. If you follow this route, as a minimum requirement, all safety-related information has to be provided in German nevertheless:
+> 
+> "In begründeten Fällen dürfen die Informationen auch in englischer Sprache oder einer anderen für den Anwender des Medizinproduktes leicht verständlichen Sprache zur Verfügung gestellt werden, wenn diese Informationen ausschließlich für professionelle Anwender bestimmt sind und die sicherheitsbezogenen Informationen auch in deutscher Sprache oder in der Sprache des Anwenders zur Verfügung gestellt werden."
+> 
+> https://www.gesetze-im-internet.de/mpdg/MPDG.pdf
+
+## Product Description
+
+### Intended Medical Indication
+
+> You can basically copy/paste your intended use document here and in the sections below. This paragraph should include high-level information required to get an idea of how your product works.
+> Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by your software.
+> Take into account: clinical benefits to be expected, types of processed data, types of data processing (or machine learning based devices: information about algorithm accuracy).
+
+### Characterization of User Profile
+
+> Describe your users: what level of education can be assumed for your users group? Any pre-existing knowledge of the field that your device is used in?
+> What technical proficiency can be assumed, how much time is typically spent using the software?
+
+> If you plan on providing user training prior to product use, make sure to also add a description of that here.
+
+### Characterization of Patient Population
+
+> Describe the patient population your software is intended to be used on. Note that this may overlap with the user profile above, 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).
+
+
+### Characterization of 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 on 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).
+
+### Exclusions
+
+> This is an important section for your company liability: make clear the environment your device should NOT be used in, by whom should your device NOT be used?
+
+
+## Safety Information
+
+### Contraindications
+
+> More exclusions, more specific to safety risks and clinical implications. For example, does your device automate medical diagnoses? If not, you may want to point out that all results must be checked thoroughly by a qualified physician.
+
+### Warning and Remaining Risks
+
+> You can use this section to point out user information as required for risk mitigation measures. For example, specific information that must be checked for accuracy or completeness to operate the device.
+
+
+## Language
+
+> Self-explanatory: what languages, what language settings are offered for your product?
+
+
+## System Requirements
+
+### Hardware
+
+> What hardware configuration is required to run your device (e.g. minimum requirements for processor, display, network bandwidth)?
+
+### Software
+
+> What software configuration is required (e.g. latest browser version)?
+
+### IT-security Measures
+
+> What is required to prevent unauthorized access? How do users prevent data loss? Describe for example firewall settings, VPN setup, etc.
+
+## Installation
+
+> Describe: Is any IT integration required prior to use? How is a successful installation verified? How are login credentials dealt with?
+
+## Safety and Maintenance
+
+> Consider multiple sub-sections here: how do you plan to deploy frontend / backend updates? How can users report malfunctions, clinical incidents, lost passwords or a potential security breach?
+
+Other aspects you may want to consider for the section as part of your instructions for use:
+
+ * Using the software: walkthrough guide to explain functionalities including screenshots and links to helpful websites
+ * Description of the algorithm for machine-learning based medical devices
+ * Description of alternative devices or services
diff --git a/openregulatory/templates/general/intended-use.md b/openregulatory/templates/general/intended-use.md
new file mode 100644
index 00000000..a1e9e54d
--- /dev/null
+++ b/openregulatory/templates/general/intended-use.md
@@ -0,0 +1,84 @@
+# 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.
diff --git a/openregulatory/templates/general/mdd-classification-document.md b/openregulatory/templates/general/mdd-classification-document.md
new file mode 100644
index 00000000..3fdb868b
--- /dev/null
+++ b/openregulatory/templates/general/mdd-classification-document.md
@@ -0,0 +1,125 @@
+# MDD Classification Document
+
+## Mapping of Requirements
+
+> NOTE: this template only serves for MDD purposes. From May 2021 on, Annex VIII MDR applies instead of Annex
+> IX MDD.
+
+| Medical Device Directive (MDD) | Document Section |
+| ------------------------------ | ---------------- |
+| Annex IX                       | (All)            |
+
+## Summary
+
+| Product:        | (enter content) |
+| --------        | --------------- |
+| Version:        | (enter content) |
+| Classification: | (enter content) |
+| Rule:           | (enter content) |
+
+## Chapter 1: Applicable Definitions
+
+> You will need to carefully check and fill out all rows below. Some rows are pre-filled for applicability
+> under the assumption of a stand-alone software medical device. However, this is a quite essential document
+> and you're better off checking twice.
+
+**1.1 Duration**
+
+| Term       | Definition                                                      | Applicable |
+| ----       | ----------                                                      | ---------- |
+| Transient  | Normally intended for continuous use for less than 60 minutes.  |            |
+| Short term | Normally intended for continuous use for not more than 30 days. |            |
+| Long term  | Normally intended for continuous use for more than 30 days.     |            |
+
+**1.2 Invasive Devices**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| **Invasive device**<br>A device which, in whole or in part, penetrates inside the body, either through a body orifice or through the surface of the body.<br>**Body orifice**<br>Any natural opening in the body, as well as the external surface of the eyeball, or any permanent artificial opening, such as a stoma.<br>**Surgically invasive device**<br>An invasive device which penetrates inside the body through the surface of the body, with the aid or in the context of a surgical operation. For the purposes of this Directive devices other than those referred to in the previous subparagraph and which produce penetration other than through an established body orifice, shall be treated as surgically invasive devices.<br>**Implantable device**<br>Any device which is intended:<br>— to be totally introduced into the human body or,<br>— to replace an epithelial surface or the surface of the eye, by surgical intervention which is intended to remain in place after the procedure.<br><br>Any device intended to be partially introduced into the human body through surgical intervention and intended to remain in place after the procedure for at least 30 days is also considered an implantable device. | No |
+
+**1.3 Reusable Surgical Instrument**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| Instrument intended for surgical use by cutting, drilling, sawing, scratching, scraping, clamping, retracting, clipping or similar procedures, without connection to any active medical device and which can be reused after appropriate procedures have been carried out. | No |
+
+**1.4 Active Medical Device**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| Any medical device operation of which depends on a source of electrical energy or any source of power other than that directly generated by the human body or gravity and which acts by converting this energy. Medical devices intended to transmit energy, substances or other elements between an active medical device and the patient, without any significant change, are not considered to be active medical devices.<br>Stand alone software is considered to be an active medical device. | Yes |
+
+**1.5 Active Therapeutical Device**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| Any active medical device, whether used alone or in combination with other medical devices, to support, modify, replace or restore biological functions or structures with a view to treatment or alleviation of an illness, injury or handicap. |  |
+
+**1.6 Active Device for Diagnosis**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| Any active medical device, whether used alone or in combination with other medical devices, to supply information for detecting, diagnosing, monitoring or treating physiological conditions, states of health, illnesses or congenital deformities. |  |
+
+**1.7 Central Circulatory System**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| For the purposes of this Directive, ‘central circulatory system’ means the following vessels:<br>arteriae pulmonales, aorta ascendens, arcus aorta, aorta descendens to the bifurcatio aortae, arteriae coronariae, arteria carotis communis, arteria carotis externa, arteria carotis interna, arteriae cerebrales, truncus brachio- cephalicus, venae cordis, venae pulmonales, vena cava superior, vena cava inferior. |  |
+
+**1.8 Central Nervous System**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| For the purposes of this Directive, ‘central nervous system’ means brain, meninges and spinal cord. |  |
+
+## Chapter 2: Implementing Rules
+
+| Rules | Applicable |
+| ----- | ---------- |
+| 2.1: Application of the classification rules shall be governed by the intended purpose of the devices. | Yes |
+| 2.2: If the device is intended to be used in combination with another device, the classification rules shall apply separately to each of the devices. Accessories are classified in their own right separately from the device with which they are used. |  |
+| 2.3: Software, which drives a device or influences the use of a device, falls automatically in the same class. |  |
+| 2.4: If the device is not intended to be used solely or principally in a specific part of the body, it must be considered and classified on the basis of the most critical specified use. |  |
+| 2.5: If several rules apply to the same device, based on the performance specified for the device by the manufacturer, the strictest rules resulting in the higher classification shall apply. |  |
+| 2.6: In calculating the duration referred to in Section 1.1 of Chapter I, continuous use means ‘an uninterrupted actual use of the device for the intended purpose’. However where usage of a device is discontinued in order for the device to be replaced immediately by the same or an identical device this shall be considered an extension of the continuous use of the device. |  |
+
+## Chapter 3: Classification Rules
+
+**1.) Non-Invasive Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 1***<br>All non-invasive devices are in Class I, unless one of the rules set out hereinafter applies. |  |
+| ***Rule 2***<br>All non-invasive devices intended for channelling or storing blood, body liquids or tissues, liquids or gases for the purpose of eventual infusion, administration or introduction into the body are in Class IIa:<br>— if they may be connected to an active medical device in Class IIa or a higher class<br>— if they are intended for use for storing or channelling blood or other body liquids or for storing organs, parts of organs or body tissues.<br>In all other cases they are in Class I. | No |
+| ***Rule 3***<br>All non-invasive devices intended for modifying the biological or chemical composition of blood, other body liquids or other liquids intended for infusion into the body are in Class IIb, unless the treatment consists of filtration, centrifugation or exchanges of gas, heat, in which case they are in Class IIa. | No |
+| ***Rule 4***<br>All non-invasive devices which come into contact with injured skin:<br>— are in Class I if they are intended to be used as a mechanical barrier, for compression or for absorption of exudates,<br>— are in Class IIb if they are intended to be used principally with wounds which have breached the dermis and can only heal by secondary intent,<br>— are in Class IIa in all other cases, including devices principally intended to manage the micro-environment of a wound. | No |
+
+**2.) Invasive Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 5***<br>All invasive devices with respect to body orifices, other than surgically invasive devices and which are not intended for connection to an active medical device or which are intended for connection to an active medical device in Class I:<br>— are in Class I if they are intended for transient use,<br>— are in Class IIa if they are intended for short-term use, except if they are used in the oral cavity as far as the pharynx, in an ear canal up to the ear drum or in a nasal cavity, in which case they are in Class I,<br>— are in Class IIb if they are intended for long-term use, except if they are used in the oral cavity as far as the pharynx, in an ear canal up to the ear drum or in a nasal cavity and are not liable to be absorbed by the mucous membrane, in which case they are in Class IIa.<br><br>All invasive devices with respect to body orifices, other than surgically invasive devices, intended for connection to an active medical device in Class IIa or a higher class, are in Class IIa. | No |
+| ***Rule 6***<br>All surgically invasive devices intended for transient use are in Class IIa unless they are:<br>— intended specifically to control, diagnose, monitor or correct a defect of the heart or of the central circulatory system through direct contact with these parts of the body, in which case they are in Class III,<br>— reusable surgical instruments, in which case they are in Class I,<br>— intended specifically for use in direct contact with the central nervous system, in which case they are in Class III,<br>— intended to supply energy in the form of ionising radiation in which case they are in Class IIb,<br>— intended to have a biological effect or to be wholly or mainly absorbed in which case they are in Class IIb,<br>— intended to administer medicines by means of a delivery system, if this is done in a manner that is potentially hazardous taking account of the mode of application, in which case they are in Class IIb. | No |
+| ***Rule 7***<br>All surgically invasive devices intended for short-term use are in Class IIa unless they are intended:<br>— either specifically to control, diagnose, monitor or correct a defect of the heart or of the central circulatory system through direct contact with these parts of the body, in which case they are in Class III,<br>— or specifically for use in direct contact with the central nervous system, in which case they are in Class III,<br>— or to supply energy in the form of ionizing radiation in which case they are in Class IIb,<br>— or to have a biological effect or to be wholly or mainly absorbed in which case they are in Class III,<br>— or to undergo chemical change in the body, except if the devices are placed in the teeth, or to administer medicines, in which case they are in Class IIb. | No |
+| ***Rule 8***<br>All implantable devices and long-term surgically invasive devices are in Class IIb unless they are intended:<br>— to be placed in the teeth, in which case they are in Class IIa,<br>— to be used in direct contact with the heart, the central circulatory system or the central nervous system, in which case they are in Class III,<br>— to have a biological effect or to be wholly or mainly absorbed, in which case they are in Class III,<br>— or to undergo chemical change in the body, except if the devices are placed in the teeth, or to administer medicines, in which case they are in Class III. | No |
+
+**3.) Additional Rules Applicable to Active Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 9***<br>All active therapeutic devices intended to administer or exchange energy are in Class IIa unless their characteristics are such that they may administer or exchange energy to or from the human body in a potentially hazardous way, taking account of the nature, the density and site of application of the energy, in which case they are in Class IIb.<br>All active devices intended to control or monitor the performance of active therapeutic devices in Class IIb, or intended directly to influence the performance of such devices are in Class IIb. |  |
+| ***Rule 10***<br>Active devices intended for diagnosis are in Class IIa:<br>— if they are intended to supply energy which will be absorbed by the human body, except for devices used to illuminate the patient's body, in the visible spectrum,<br>— if they are intended to image in vivo distribution of radiopharmaceuticals,<br>— if they are intended to allow direct diagnosis or monitoring of vital physiological processes, unless they are specifically intended for monitoring of vital physiological parameters, where the nature of variations is such that it could result in immediate danger to the patient, for instance variations in cardiac performance, respiration, activity of CNS in which case they are in Class IIb.<br><br>Active devices intended to emit ionizing radiation and intended for diagnostic and therapeutic interventional radiology including devices which control or monitor such devices, or which directly influence their performance, are in Class IIb. |  |
+| ***Rule 11***<br>All active devices intended to administer and/or remove medicines, body liquids or other substances to or from the body are in Class IIa, unless this is done in a manner:<br>— that is potentially hazardous, taking account of the nature of the substances involved, of the part of the body concerned and of the mode of application in which case they are in Class IIb. |  |
+| ***Rule 12***<br>All other active devices are in Class I. |  |
+
+**4.) Special Rules**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 13***<br>All devices incorporating, as an integral part a substance which, if used separately, can be considered to be a medicinal product, as defined in Article 1 of Directive 2001/83/EC, and which is liable to act on the human body with action ancillary to that of the devices, are in Class III. All devices incorporating, as an integral part, a human blood derivative are in Class III. | No |
+| ***Rule 14***<br>All devices used for contraception or the prevention of the transmission of sexually transmitted diseases are in Class IIb, unless they are implantable or long term invasive devices, in which case they are in Class III. | No |
+| ***Rule 15***<br>All devices intended specifically to be used for disinfecting, cleaning, rinsing or, when appropriate, hydrating contact lenses are in Class IIb. All devices intended specifically to be used for disinfecting medical devices are in Class IIa. Unless they are specifically to be used for disinfecting invasive devices in which case they are in Class IIb.<br><br>This rule does not apply to products that are intended to clean medical devices other than contact lenses by means of physical action. | No |
+| ***Rule 16***<br>Devices specifically intended for recording of X-ray diagnostic images are in Class IIa. | No |
+| ***Rule 17***<br>All devices manufactured utilizing animal tissues or derivatives rendered non-viable are Class III except where such devices are intended to come into contact with intact skin only. | No |
+| ***Rule 18***<br>By derogation from other rules, blood bags are in Class IIb. | No |
diff --git a/openregulatory/templates/general/mdr-classification-document.md b/openregulatory/templates/general/mdr-classification-document.md
new file mode 100644
index 00000000..d36f3941
--- /dev/null
+++ b/openregulatory/templates/general/mdr-classification-document.md
@@ -0,0 +1,102 @@
+# MDR Classification Document
+
+## Mapping of Requirements
+
+> NOTE: this template only serves for MDR purposes. Before May 2021, use Annex IX MDD instead of Annex VIII
+> MDR.
+
+| Medical Device Regulation (MDR) | Document Section |
+| ------------------------------- | ---------------- |
+| Annex VIII | (All) |
+
+## Summary
+
+| Product: | (enter content) |
+| -------- | --------------- |
+| Version: | (enter content) |
+| Classification: | (enter content) |
+| Rule: | (enter content) |
+
+## Chapter 1: Applicable Definitions
+
+> You will need to carefully check and fill out all rows below. Some rows are pre-filled for applicability
+> under the assumption of a stand-alone software medical device. However, this is quite an essential document
+> and you're better off checking twice.
+
+**1. Duration of Use**
+
+| Term       | Definition                                                      | Applicable |
+|------------|-----------------------------------------------------------------|------------|
+| Transient  | Normally intended for continuous use for less than 60 minutes.  |            |
+| Short term | Normally intended for continuous use for not more than 30 days. |            |
+| Long term  | Normally intended for continuous use for more than 30 days.     |            |
+|            |                                                                 |            |
+
+**2. Invasive and Active Devices**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| **2.1 Body orifice** means any natural opening in the body, as well as the external surface of the eyeball, or any permanent artificial opening, such as a stoma. | No |
+| **2.2 Surgically invasive device** means:<br>(a) an invasive device which penetrates inside the body through the surface of the body, including through mucous membranes of body orifices with the aid or in the context of a surgical operation; and<br>(b) a device which produces penetration other than through a body orifice. | No |
+| **2.3 Reusable surgical instrument** means an instrument intended for surgical use in cutting, drilling, sawing, scratching, scraping, clamping, retracting, clipping or similar procedures, without a connection to an active device and which is intended by the manufacturer to be reused after appropriate procedures such as cleaning, disinfection and sterilization have been carried out. | No |
+| **2.4 Active therapeutic device** means any active device used, whether alone or in combination with other devices, to<br>support, modify, replace or restore biological functions or structures with a view to treatment or alleviation of an<br>illness, injury or disability. |  |
+| **2.5 Active device intended for diagnosis and monitoring** means any active device used, whether alone or in combination with other devices, to supply information for detecting, diagnosing, monitoring or treating physio logical conditions, states of health, illnesses or congenital deformities. |  |
+| **2.6 Central circulatory system** means the following blood vessels:<br>arteriae pulmonales, aorta ascendens, arcus aortae, aorta descendens to the bifurcatio aortae, arteriae coronariae, arteria carotis communis, arteria carotis externa, arteria carotis interna, arteriae cerebrales, truncus brachiocephalicus, venae cordis, venae pulmonales, vena cava superior and vena cava inferior. |  |
+| **2.7 Central nervous system** means the brain, meninges and spinal cord. |  |
+| **2.8 Injured skin or mucous membrane** means an area of skin or a mucous membrane presenting a pathological<br>change or change following disease or a wound. |  |
+
+## Chapter 2: Implementing Rules
+
+| Rules | Applicable |
+| ----- | ---------- |
+| **3.1** Application of the classification rules shall be governed by the intended purpose of the devices. | Yes |
+| **3.2** If the device in question is intended to be used in combination with another device, the classification rules shall apply separately to each of the devices. Accessories for a medical device and for a product listed in Annex XVI MDR shall be classified in their own right separately from the device with which they are used. |  |
+| **3.3** Software, which drives a device or influences the use of a device, shall fall within the same class as the device.<br>If the software is independent of any other device, it shall be classified in its own right. |  |
+| **3.4** If the device is not intended to be used solely or principally in a specific part of the body, it shall be considered and classified on the basis of the most critical specified use. |  |
+| **3.5** If several rules, or if, within the same rule, several sub-rules, apply to the same device based on the device's intended purpose, the strictest rule and sub-rule resulting in the higher classification shall apply. |  |
+| **3.6** In calculating the duration referred to in Section 1, continuous use shall mean:<br>(a) the entire duration of use of the same device without regard to temporary interruption of use during a procedure or temporary removal for purposes such as cleaning or disinfection of the device. Whether the interruption of use or the removal is temporary shall be established in relation to the duration of the use prior to and after the period when the use is interrupted or the device removed; and<br>(b) the accumulated use of a device that is intended by the manufacturer to be replaced immediately with another of the same type. |  |
+| **3.7** A device is considered to allow direct diagnosis when it provides the diagnosis of the disease or condition in question by itself or when it provides decisive information for the diagnosis. |  |
+
+## Chapter 3: Classification Rules
+
+**4.) Non-Invasive Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 1***<br>All non-invasive devices are classified as class I, unless one of the rules set out hereinafter applies. |  |
+| ***Rule 2***<br>All non-invasive devices intended for channelling or storing blood, body liquids, cells or tissues, liquids or gases for the purpose of eventual infusion, administration or introduction into the body are classified as class IIa:<br>— if they may be connected to a class IIa, class IIb or class III active device; or<br>— if they are intended for use for channelling or storing blood or other body liquids or for storing organs, parts<br>of organs or body cells and tissues, except for blood bags; blood bags are classified as class IIb.<br>In all other cases, such devices are classified as class I. | No |
+| ***Rule 3***<br>All non-invasive devices intended for modifying the biological or chemical composition of human tissues or cells, blood, other body liquids or other liquids intended for implantation or administration into the body are classified as class IIb, unless the treatment for which the device is used consists of filtration, centrifugation or exchanges of gas, heat, in which case they are classified as class IIa.<br><br>All non-invasive devices consisting of a substance or a mixture of substances intended to be used in vitro in direct<br>contact with human cells, tissues or organs taken from the human body or used in vitro with human embryos<br>before their implantation or administration into the body are classified as class III. | No |
+| ***Rule 4***<br>All non-invasive devices which come into contact with injured skin or mucous membrane are classified as:<br>— class I if they are intended to be used as a mechanical barrier, for compression or for absorption of exudates;<br>— class IIb if they are intended to be used principally for injuries to skin which have breached the dermis or<br>mucous membrane and can only heal by secondary intent;<br>— class IIa if they are principally intended to manage the micro-environment of injured skin or mucous membrane; and<br>— class IIa in all other cases.<br><br>This rule applies also to the invasive devices that come into contact with injured mucous membrane. | No |
+
+**5.) Invasive Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 5***<br>All invasive devices with respect to body orifices, other than surgically invasive devices, which are not intended for connection to an active device or which are intended for connection to a class I active device are classified as:<br>— class I if they are intended for transient use;<br>— class IIa if they are intended for short-term use, except if they are used in the oral cavity as far as the pharynx, in an ear canal up to the ear drum or in the nasal cavity, in which case they are classified as class I; and<br>— class IIb if they are intended for long-term use, except if they are used in the oral cavity as far as the pharynx, in an ear canal up to the ear drum or in the nasal cavity and are not liable to be absorbed by the mucous membrane, in which case they are classified as class IIa.<br><br>All invasive devices with respect to body orifices, other than surgically invasive devices, intended for connection<br>to a class IIa, class IIb or class III active device, are classified as class IIa. | No |
+| ***Rule 6***<br>All surgically invasive devices intended for transient use are classified as class IIa unless they:<br>— are intended specifically to control, diagnose, monitor or correct a defect of the heart or of the central circulatory system through direct contact with those parts of the body, in which case they are classified as class III;<br>— are reusable surgical instruments, in which case they are classified as class I;<br>— are intended specifically for use in direct contact with the heart or central circulatory system or the central nervous system, in which case they are classified as class III;<br>— are intended to supply energy in the form of ionising radiation in which case they are classified as class IIb;<br>— have a biological effect or are wholly or mainly absorbed in which case they are classified as class IIb; or<br>— are intended to administer medicinal products by means of a delivery system, if such administration of a medicinal product is done in a manner that is potentially hazardous taking account of the mode of application, in which case they are classified as class IIb. | No |
+| ***Rule 7***<br>All surgically invasive devices intended for short-term use are classified as class IIa unless they:<br>— are intended specifically to control, diagnose, monitor or correct a defect of the heart or of the central circulatory system through direct contact with those parts of the body, in which case they are classified as class III;<br>— are intended specifically for use in direct contact with the heart or central circulatory system or the central nervous system, in which case they are classified as class III;<br>— are intended to supply energy in the form of ionizing radiation in which case they are classified as class IIb;<br>— have a biological effect or are wholly or mainly absorbed in which case they are classified as class III;<br>— are intended to undergo chemical change in the body in which case they are classified as class IIb, except if the devices are placed in the teeth; or<br>— are intended to administer medicines, in which case they are classified as class IIb. | No |
+| ***Rule 8***<br>All implantable devices and long-term surgically invasive devices are classified as class IIb unless they:<br>— are intended to be placed in the teeth, in which case they are classified as class IIa;<br>— are intended to be used in direct contact with the heart, the central circulatory system or the central nervous system, in which case they are classified as class III;<br>— have a biological effect or are wholly or mainly absorbed, in which case they are classified as class III;<br>— are intended to undergo chemical change in the body in which case they are classified as class III, except if the devices are placed in the teeth;<br>— are intended to administer medicinal products, in which case they are classified as class III;<br>— are active implantable devices or their accessories, in which cases they are classified as class III;<br>— are breast implants or surgical meshes, in which cases they are classified as class III;<br>— are total or partial joint replacements, in which case they are classified as class III, with the exception of ancillary components such as screws, wedges, plates and instruments; or<br>— are spinal disc replacement implants or are implantable devices that come into contact with the spinal column, in which case they are classified as class III with the exception of components such as screws, wedges, plates and instruments. | No |
+
+**6.) Active Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 9***<br>All active therapeutic devices intended to administer or exchange energy are classified as class IIa unless their characteristics are such that they may administer energy to or exchange energy with the human body in a potentially hazardous way, taking account of the nature, the density and site of application of the energy, in which case they are classified as class IIb.<br><br>All active devices intended to control or monitor the performance of active therapeutic class IIb devices, or intended directly to influence the performance of such devices are classified as class IIb.<br><br>All active devices intended to emit ionizing radiation for therapeutic purposes, including devices which control or monitor such devices, or which directly influence their performance, are classified as class IIb.<br><br>All active devices that are intended for controlling, monitoring or directly influencing the performance of active implantable devices are classified as class III. |  |
+| ***Rule 10***<br>Active devices intended for diagnosis and monitoring are classified as class IIa:<br>— if they are intended to supply energy which will be absorbed by the human body, except for devices intended to illuminate the patient's body, in the visible spectrum, in which case they are classified as class I;<br>— if they are intended to image in vivo distribution of radiopharmaceuticals; or<br>— if they are intended to allow direct diagnosis or monitoring of vital physiological processes, unless they are specifically intended for monitoring of vital physiological parameters and the nature of variations of those parameters is such that it could result in immediate danger to the patient, for instance variations in cardiac performance, respiration, activity of the central nervous system, or they are intended for diagnosis in clinical situations where the patient is in immediate danger, in which cases they are classified as class IIb.<br><br>Active devices intended to emit ionizing radiation and intended for diagnostic or therapeutic radiology, including interventional radiology devices and devices which control or monitor such devices, or which directly influence their performance, are classified as class IIb. |  |
+| ***Rule 11***<br>Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:<br>— death or an irreversible deterioration of a person's state of health, in which case it is in class III; or<br>— a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb.<br><br>Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I. | Yes |
+| ***Rule 12***<br>All active devices intended to administer and/or remove medicinal products, body liquids or other substances to or from the body are classified as class IIa, unless this is done in a manner that is potentially hazardous, taking account of the nature of the substances involved, of the part of the body concerned and of the mode of application in which case they are classified as class IIb. |  |
+| ***Rule 13***<br>All other active devices are classified as class I. |  |
+
+**7.) Special Rules**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 14***<br>All devices incorporating, as an integral part, a substance which, if used separately, can be considered to be a medicinal product, as defined in point 2 of Article 1 of Directive 2001/83/EC, including a medicinal product derived from human blood or human plasma, as defined in point 10 of Article 1 of that Directive, and that has an action ancillary to that of the devices, are classified as class III. | No |
+| ***Rule 15***<br>All devices used for contraception or prevention of the transmission of sexually transmitted diseases are classified as class IIb, unless they are implantable or long term invasive devices, in which case they are classified as class III. | No |
+| ***Rule 16***<br>All devices intended specifically to be used for disinfecting, cleaning, rinsing or, where appropriate, hydrating contact lenses are classified as class IIb.<br><br>All devices intended specifically to be used for disinfecting or sterilising medical devices are classified as class IIa, unless they are disinfecting solutions or washer-disinfectors intended specifically to be used for disinfecting invasive devices, as the end point of processing, in which case they are classified as class IIb.<br><br>This rule does not apply to devices that are intended to clean devices other than contact lenses by means of physical action only. | No |
+| ***Rule 17***<br>Devices specifically intended for recording of diagnostic images generated by X-ray radiation are classified as class IIa. | No |
+| ***Rule 18***<br>All devices manufactured utilizing tissues or cells of human or animal origin, or their derivatives, which are non-viable or rendered non-viable, are classified as class III, unless such devices are manufactured utilizing tissues or cells of animal origin, or their derivatives, which are non-viable or rendered non-viable and are devices intended to come into contact with intact skin only. | No |
+| ***Rule 19***<br>All devices incorporating or consisting of nanomaterial are classified as:<br>— class III if they present a high or medium potential for internal exposure;<br>— class IIb if they present a low potential for internal exposure; and<br>— class IIa if they present a negligible potential for internal exposure. | No |
+| ***Rule 20***<br>All invasive devices with respect to body orifices, other than surgically invasive devices, which are intended to administer medicinal products by inhalation are classified as class IIa, unless their mode of action has an essential impact on the efficacy and safety of the administered medicinal product or they are intended to treat life-threatening conditions, in which case they are classified as class IIb. | No |
+| ***Rule 21***<br>Devices that are composed of substances or of combinations of substances that are intended to be introduced into the human body via a body orifice or applied to the skin and that are absorbed by or locally dispersed in the human body are classified as:<br>— class III if they, or their products of metabolism, are systemically absorbed by the human body in order to achieve the intended purpose;<br>— class III if they achieve their intended purpose in the stomach or lower gastrointestinal tract and they, or their products of metabolism, are systemically absorbed by the human body;<br>— class IIa if they are applied to the skin or if they are applied in the nasal or oral cavity as far as the pharynx, and achieve their intended purpose on those cavities; and<br>— class IIb in all other cases. | No |
+| ***Rule 22***<br>Active therapeutic devices with an integrated or incorporated diagnostic function which significantly determines the patient management by the device, such as closed loop systems or automated external defibrillators, are classified as class III. |  |
diff --git a/openregulatory/templates/pandoc_html.css b/openregulatory/templates/pandoc_html.css
new file mode 100644
index 00000000..adab716d
--- /dev/null
+++ b/openregulatory/templates/pandoc_html.css
@@ -0,0 +1,25 @@
+table {
+  border-spacing: 0;
+}
+
+table th {
+  background-color: gray;
+  color: white;
+  padding: 3px 10px;
+  border-top: none;
+  border-left: none;
+  border-right: none;
+}
+
+table td {
+  padding: 3px 10px;
+  border-top: none;
+  border-left: none;
+  border-bottom: none;
+  border-right: none;
+}
+
+/* Borders between columns */
+
+table td + td { border-left: 1px solid black; }
+table th + th { border-left: 1px solid black; }
diff --git a/openregulatory/templates/performance_evaluation/performance-evaluation-plan-ivdd.md b/openregulatory/templates/performance_evaluation/performance-evaluation-plan-ivdd.md
new file mode 100644
index 00000000..55b1e47a
--- /dev/null
+++ b/openregulatory/templates/performance_evaluation/performance-evaluation-plan-ivdd.md
@@ -0,0 +1,157 @@
+# Performance Evaluation Plan (IVDD)
+
+The Performance Evaluation Plan lays out the resources and methods for the evaluation of the performance of the IVD.
+
+> There's a separate standard available for that: EN 13612:2002. It's very short and doesn't contain a whole
+> lot of information. You can generally understand what it's about when you look at the mapping of
+> requirements to document sections table below. Additionally, there are three IMDRF guidance documents which
+> are more relevant for the Performance Evaluation Report:
+>
+> * [GHTF/SG5/N6:2012][imdrf-1]
+> * [GHTF/SG5/N7:2012][imdrf-2]
+> * [GHTF/SG5/N8:2012][imdrf-3]
+
+## Product
+
+ * Name: *\<product name\>*
+ * Version: *\<product version\>*
+ * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
+
+## Mapping of Requirements to Document Sections
+
+| EN 13612:2002 Section                                    | Document                               | Section |
+|----------------------------------------------------------|----------------------------------------|---------|
+| 3.1 Responsibilities and Resources                       | Performance Evaluation Plan (this one) | 5       |
+| 3.2 Documentation                                        | Performance Evaluation Plan (this one) | (all)   |
+| 3.3 Final Assessment and Review                          | Performance Evaluation Report          |         |
+| 4.1 Preconditions                                        | Performance Evaluation Report          |         |
+| 4.2 Evaluation Plan                                      | Performance Evaluation Plan (this one) | 6, 7    |
+| 4.3 Sites and Resources                                  | Performance Evaluation Plan (this one) | 5       |
+| 4.4 Basic Design Information                             | Performance Evaluation Plan (this one) | 7.3     |
+| 4.5 Experimental Design                                  | Performance Evaluation Plan (this one) | 7.4     |
+| 4.6 Performance Study Records                            | Performance Evaluation Plan (this one) | 7.5     |
+| 4.7 Observations and Unexpected Outcomes                 | Performance Evaluation Plan (this one) | 7.6     |
+| 4.8 Evaluation Report                                    | Performance Evaluation Report          |         |
+| 5. Modifications During the Performance Evaluation Study | Performance Evaluation Plan (this one) | 8       |
+| 6. Re-evaluation                                         | Performance Evaluation Plan (this one) | 8       |
+| 7. Protection and Safety of Probands                     | Performance Evaluation Plan (this one) | 9       |
+
+## 1. List of Abbreviations
+
+| Abbreviation | Explanation                        |
+|--------------|------------------------------------|
+| IVD MD       | In-vitro diagnostic medical device |
+
+## 2. Product
+
+ * Name: *\<product name\>*
+ * Version: *\<product version\>*
+ * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
+ * UMDNS-Code:
+ * GMDN-Code:
+
+## 3. Relevant Documents
+
+ * SOP Performance Evaluation
+ * Performance Evaluation Plan
+
+## 4. Intended Use
+
+> Copy-paste the intended use of your device here.
+
+## 5. Responsibilities and Resources
+
+### 5.1 Personnel
+
+> These five tasks are explicitly specified in EN 13612, so you should assign them to someone. Feel free to
+> add further tasks if you have any. Of course, one person can take care of multiple tasks.
+
+| Task                                                                    | Personnel       |
+|-------------------------------------------------------------------------|-----------------|
+| Coordinator with overall responsibility                                 | John Doe        |
+| Assess the validity of test results and data already available          | John Doe Jr.    |
+| Specify performance claims which shall be further examined or confirmed | John Doe Sr.    |
+| Specify and document the evaluation plan and the test procedures        | John Doe II     |
+| Prepare the evaluation report                                           | Albert Einstein |
+
+### 5.2 Resources
+
+> Describe other resources which you need for performance evaluation, e.g. software and hardware, physical
+> locations.
+
+## 6. Performance Claims of IVD MD
+
+> For each performance claim, assess whether it's applicable to your IVD, i.e. can you measure that specific
+> parameter, based on your device output? Then, add an explanation about what those parameters actually mean
+> in the context of your device.
+>
+> An example could be that you're manufacturing an HIV test. Then, analytical sensitivity is applicable, and
+> your explanation would be something like "proportion of HIV-positive patients who have positive test
+> results".
+
+| Performance Claim      | Applicable? | Explanation |
+|------------------------|-------------|-------------|
+| Analytical Sensitivity | yes/no      |             |
+| Diagnostic Sensitivity |             |             |
+| Analytical Specificity |             |             |
+| Diagnostic Specificity |             |             |
+| Accuracy               |             |             |
+| Repeatability          |             |             |
+| Reproducibility        |             |             |
+
+## 7. Evaluation Procedure
+
+### 7.1 List of Laboratories and Other Institutions Taking Part in Study
+
+> List the labs which take part in your study. If your product is for self-testing, list the "lay persons" who
+> are your study participants.
+
+### 7.2 Time Table
+
+> Create some sort of timeline when to do what.
+
+| Date | Activity                            |
+|------|-------------------------------------|
+|      | Plan Performance Evaluation         |
+|      | Conduct Performance Evaluation      |
+|      | Write Performance Evaluation Report |
+
+### 7.3 Briefing of Investigators
+
+> If your investigators (the people who conduct the study) aren't familiar with your device, describe how
+> you'll provide them with the necessary information beforehand.
+
+### 7.4 Software Validation
+
+The device is stand-alone software and will be validated in accordance with IEC 62366-1:2015, see SOP
+Integrated Software Development.
+
+### 7.5 Performance Study Records
+
+> Describe how and where records of your performance study will be saved. Those could be files which contain
+> your analysis data, or even the input data (i.e., test set) which you used for it.
+
+### 7.6 Observations and Unexpected Outcomes
+
+> Describe what you'll do when an unexpected outcome happens. Might not apply to stand-alone software.
+
+### 8. Re-Evaluation
+
+> Specify under which conditions your performance evaluation will be repeated. That's mainly the case when you
+> change your device.
+
+### 9. Protection and Safety of Probands
+
+> Describe how you ensure the safety of your probands. Probably not be applicable to software in most cases.
+
+## 10. Dates and Signatures
+
+> Date and sign the plan. If your document management system supports it, you can digitally sign by typing
+> e.g. your initials in the "Signature" field. Otherwise, you can still sign it the old-school way (print it
+> and sign the sheet of paper, ugh).
+
+| Activity | Name | Signature |
+|-----------|------|-----------|
+| Creation  |      |           |
+| Review    |      |           |
+| Approval  |      |           |
diff --git a/openregulatory/templates/performance_evaluation/performance-evaluation-report-ivdd.md b/openregulatory/templates/performance_evaluation/performance-evaluation-report-ivdd.md
new file mode 100644
index 00000000..2420f267
--- /dev/null
+++ b/openregulatory/templates/performance_evaluation/performance-evaluation-report-ivdd.md
@@ -0,0 +1,193 @@
+# Performance Evaluation Report (IVDD)
+
+The Performance Evaluation Report contains the methods and results regarding scientific validity, analytical
+performance and clinical performance.
+
+> There's a separate standard available for that: EN 13612:2002. It's very short and doesn't contain a whole
+> lot of information. Additionally, there are three IMDRF guidance documents:
+>
+> * [GHTF/SG5/N6:2012][imdrf-1]
+> * [GHTF/SG5/N7:2012][imdrf-2]
+> * [GHTF/SG5/N8:2012][imdrf-3]
+
+## Product
+
+ * Name: *\<product name\>*
+ * Version: *\<product version\>*
+ * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
+
+## Mapping of Requirements to Document Sections
+
+| EN 13612:2002 Section                                    | Document                                 | Section |
+|----------------------------------------------------------|------------------------------------------|---------|
+| 3.1 Responsibilities and Resources                       | Performance Evaluation Plan              |         |
+| 3.2 Documentation                                        | Performance Evaluation Plan              |         |
+| 3.3 Final Assessment and Review                          | Performance Evaluation Report (this one) | 10      |
+| 4.1 Preconditions                                        | Performance Evaluation Report (this one) | 7, 8, 9 |
+| 4.2 Evaluation Plan                                      | Performance Evaluation Plan              |         |
+| 4.3 Sites and Resources                                  | Performance Evaluation Plan              |         |
+| 4.4 Basic Design Information                             | Performance Evaluation Plan              |         |
+| 4.5 Experimental Design                                  | Performance Evaluation Plan              |         |
+| 4.6 Performance Study Records                            | Performance Evaluation Plan              |         |
+| 4.7 Observations and Unexpected Outcomes                 | Performance Evaluation Plan              |         |
+| 4.8 Evaluation Report                                    | Performance Evaluation Report (this one) | (all)   |
+| 5. Modifications During the Performance Evaluation Study | Performance Evaluation Plan              |         |
+| 6. Re-evaluation                                         | Performance Evaluation Plan              |         |
+| 7. Protection and Safety of Probands                     | Performance Evaluation Plan              |         |
+
+## 1. List of Abbreviations
+
+| Abbreviation | Explanation                        |
+|--------------|------------------------------------|
+| IVD MD       | In-vitro diagnostic medical device |
+
+## 2. Product
+
+ * Name: *\<product name\>*
+ * Version: *\<product version\>*
+ * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
+ * UMDNS-Code:
+ * GMDN-Code:
+
+## 3. Relevant Documents
+
+ * SOP Performance Evaluation
+ * Performance Evaluation Plan
+
+## 4. Intended Use
+
+> Copy-paste the intended use of your device here.
+
+## 5. Risk Analysis
+
+> Copy-paste the summary of your Risk Analysis Report here.
+
+## 6. Medical Context and State of the Art
+
+### 6.1 Medical Context
+
+> Summarize in which medical context your IVD is used. If it's an HIV test, it may be used for screening, or
+> maybe only for people who think they've recently gotten infected with HIV.
+
+### 6.2 State of the Art
+
+> Describe how this is currently done. Continuing the example above: What happens currently to those patients
+> who are screened for HIV, or those who think they've gotten infected? Are there any specific tests out there
+> or is the state-of-the-art procedure another one, like (random example) doing a chest x-ray?
+
+## 7. Scientific Validity
+
+> This is generally based on literature research. Whatever your IVD is measuring, the current scientific
+> knowledge has some sort of (valid) reason for this, because it is associated with some sort of condition. Can
+> you still follow?
+>
+> Here's an example: You've developed an HIV test. Based on current scientific knowledge, it makes sense to do
+> HIV tests on people because it's established that HIV is a non-benign disease which will lead to AIDS some
+> time in the future. Early detection is useful because early treatment leads to favourable
+> outcomes. Therefore, it's scientifically valid to do HIV tests.
+
+### 7.1 Scientific Validity: Literature Search Methods
+
+> Describe your methods for your literature research for scientific validity. You'll probably have a list of
+> keywords which you'll be entering in certain databases (or other literature sources).
+>
+> Some example literature sources from guidance document GHTF/SG5/N7:2012:
+>
+> * Scientific databases – bibliographic (e.g., MEDLINE, EMBASE);
+> * Specialized databases (e.g., MEDION);
+> * Systematic review databases (e.g., Cochrane Collaboration);
+> * Clinical trial registers (e.g., CENTRAL, NIH);
+> * Adverse event report databases (e.g., MAUDE, IRIS);
+> * Scientific databases – bibliographic (e.g., MEDLINE, EMBASE);
+> * Specialized databases (e.g., MEDION);
+> * Systematic review databases (e.g., Cochrane Collaboration);
+> * Clinical trial registers (e.g., CENTRAL, NIH);
+> * Adverse event report databases (e.g., MAUDE, IRIS);
+> * Reference texts
+
+### 7.2 Scientific Validity: Literature Search Results
+
+> Describe your search results from your literature research
+
+| Database | Search term | # Hits | # Evaluated Abstracts | # Potential Relevant Publications |
+|----------|-------------|--------|-----------------------|-----------------------------------|
+|          |             |        |                       |                                   |
+
+| Database | Title | Author | Year | Summary | Relevant? Why? |
+|----------|-------|--------|------|---------|----------------|
+|          |       |        |      |         |                |
+
+### 7.3 Scientific Validity: Literature Search Conclusion
+
+> This is a bit like the "discussion" section in a scientific paper. You reach some sort of conclusion, based
+> on your literature search. In the HIV test example, this would be something like "testing for HIV is useful
+> because HIV is the disease which subsequently leads to AIDS, and early detection of that is good".
+
+## 8. Analytical Performance
+
+> Pretty simple. Describe the metrics by which your IVD detects whatever it should detect.
+>
+> In the HIV test example, those could be sensitivity / specificity values, in other words: If I use this test
+> on 100 blood samples from different patients, what sort of analytical performance can I expect?
+>
+> This will require you to run your test on some sort of test set and do some analysis of those results.
+
+### 8.1 Analytical Performance: Methods
+
+> Describe your methods. If you have a Machine Learning model, you could describe your test set and why you
+> chose that specific dataset as a test set. You could also describe the metrics by which you evaluate the
+> performance of your ML model.
+
+### 8.2 Analytical Performance: Results
+
+> Describe your results. Again, similar to a peer-reviewed paper.
+
+## 9. Clinical Performance
+
+> Slightly harder to comprehend and a bit similar to Scientific Validity. These are the performance metrics of
+> your product in its intended patient population.
+>
+> So, for the HIV test: You'll have some numbers for the analytical performance, but that's only on the
+> "reagent" level. What are the metrics when you actually use that test on real people? There's probably a
+> different sensitivity / specificity. Maybe certain comorbidities (like other viral diseases) may lead to
+> false-positive test results. So, this is like analytical performance, but in the real world, on real
+> patients.
+>
+> You can also do a literature research for this, or do a clinical performance study.
+
+### 9.1 Clinical Performance: Methods
+
+> Describe the methods of your clinical performance evaluation.
+
+### 9.2 Clinical Performance: Results
+
+> Describe your results.
+
+## 10. Conclusion
+
+> Conclude why your IVD is safe and effective to use. It makes sense to refer to your intended use, the risks
+> in your risk analysis, and the scientific validity, analytical performance and clinical performance.
+
+## 11. Dates and Signatures
+
+> Date and sign the plan. If your document management system supports it, you can digitally sign by typing
+> e.g., your initials in the "Signature" field. Otherwise, you can still sign it the old-school way (print it
+> and sign the sheet of paper, ugh).
+
+| Activity | Name | Signature |
+|-----------|------|-----------|
+| Creation  |      |           |
+| Review    |      |           |
+| Approval  |      |           |
+
+## 12. Qualification of the Responsible Evaluators
+
+> Attach CVs of the people who were involved in writing the Performance Evaluation. They must be "adequately
+> skilled and trained".
+
+
+<!-- Links -->
+
+[imdrf-1]: http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n6-2012-clinical-evidence-ivd-medical-devices-121102.pdf
+[imdrf-2]: http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n7-2012-scientific-validity-determination-evaluation-121102.pdf
+[imdrf-3]: http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n8-2012-clinical-performance-studies-ivd-medical-devices-121102.pdf
diff --git a/openregulatory/templates/qms/13485-mapping.md b/openregulatory/templates/qms/13485-mapping.md
new file mode 100644
index 00000000..acc1b401
--- /dev/null
+++ b/openregulatory/templates/qms/13485-mapping.md
@@ -0,0 +1,47 @@
+# ISO 13485:2016 Mapping of Requirements to Documents
+
+This table maps all requirements of the ISO 13485:2016 (by section) to the relevant documents.
+
+> Note that the document names in the "Fulfilled in Document" column are based on the OpenRegulatory
+> templates. You'll probably have a different system for assigning document names, so feel free to rename
+> them.
+
+## **ISO 13485:2016**
+
+| Section | Title                                             | Document                                                                                                         |
+|---------|---------------------------------------------------|------------------------------------------------------------------------------------------------------------------|
+| 4.1     | General QMS Requirements                          | *Quality Management Manual*<br>*SOP Management Review*<br>*SOP Purchasing*<br>*SOP Software Validation*          |
+| 4.2.1   | General Documentation Requirements                | *Quality Management Manual*                                                                                      |
+| 4.2.2   | Quality Management Manual                         | *Quality Management Manual*                                                                                      |
+| 4.2.3   | Medical Device File                               | *SOP Product Certification and Registration*<br>*SOP Integrated Software Development*                            |
+| 4.2.4   | Control of Documents                              | *SOP Document and Record Control*                                                                                |
+| 4.2.5   | Control of Records                                | *SOP Document and Record Control*                                                                                |
+| 5.1     | Management Obligations                            | *Quality Management Manual*<br>*Template Annual Strategic Goals*<br>*SOP Management Review*                      |
+| 5.2     | Client Orientation                                | *SOP Update of Regulations*<br>*Template Annual Strategic Goals*                                                 |
+| 5.3     | Quality Policies                                  | *Quality Management Manual*<br>*Template Annual Strategic Goals*<br>*SOP Management Review*                      |
+| 5.4     | QMS Planning and Quality Goals                    | *Quality Management Manual*<br>*Template Annual Strategic Goals*<br>*SOP Management Review*                      |
+| 5.5     | Responsibilities, Competencies and Communication  | *Quality Management Manual*                                                                                      |
+| 5.6     | Management Review                                 | *SOP Management Review*                                                                                          |
+| 6.1     | Allocation of Resources                           | *Template Annual Strategic Goals*<br>*SOP Management Review*                                                     |
+| 6.2     | Staff Resources                                   | *SOP Human Resources Administration*                                                                             |
+| 6.3     | Infrastructure                                    | *SOP Software Validation*                                                                                        |
+| 6.4     | Work Environment                                  | *\- not applicable \-*                                                                                           |
+| 6.4.2   | Control of Contamination                          | *\- not applicable \-*                                                                                           |
+| 7.1     | Planning of Product Development                   | *SOP Integrated Software Development*                                                                            |
+| 7.2     | Customer-Oriented Processes                       | *SOP Integrated Software Development*<br>*SOP Feedback Management*                                               |
+| 7.3     | Development                                       | *SOP Integrated Software Development*<br>*SOP Product Certification and Registration*<br>*SOP Change Management* |
+| 7.4     | Purchasing                                        | *SOP Purchasing*                                                                                                 |
+| 7.5     | Production and Service Provision                  | *SOP Integrated Software Development*                                                                            |
+| 7.5.5   | Special Requirements for Sterile Medical Devices  | *\- not applicable \-*                                                                                           |
+| 7.5.9   | Traceability                                      | *SOP Product Certification and Registration*                                                                     |
+| 7.6     | Control of Surveillance and Measurement           | *SOP Post-Market Surveillance*<br>*SOP Computerized Software Validation*                                         |
+| 8.1     | General Measurement, Analysis and Improvement     | *SOP Integrated Software Development*<br>*SOP Internal Auditing*<br>*SOP Management Review*                      |
+| 8.2.1   | Feedback                                          | *SOP Feedback Management*                                                                                        |
+| 8.2.2   | Complaint Processing                              | *SOP Feedback Management*<br>*SOP Corrective and Preventive Actions*                                             |
+| 8.2.3   | Reporting to Authorities                          | *SOP Incident Reporting*                                                                                         |
+| 8.2.4   | Internal Audit                                    | *SOP Internal Auditing*                                                                                          |
+| 8.2.5   | Surveillance and Measurement of Processes         | *SOP Management Review*                                                                                          |
+| 8.2.6   | Surveillance and Measurement of Products          | *SOP Post-Market Surveillance*                                                                                   |
+| 8.3     | Control of Nonconforming Products                 | *SOP Corrective and Preventive Actions*<br>*SOP Incident Reporting*                                              |
+| 8.4     | 8.4 Data Analysis                                 | *SOP Management Review*                                                                                          |
+| 8.5     | 8.5 Improvement: Corrective and Preventive Action | *SOP Corrective and Preventive Actions*                                                                          |
diff --git a/openregulatory/templates/qms/capa/list-capa.md b/openregulatory/templates/qms/capa/list-capa.md
new file mode 100644
index 00000000..ea92b267
--- /dev/null
+++ b/openregulatory/templates/qms/capa/list-capa.md
@@ -0,0 +1,21 @@
+# List of CAPAs
+
+| ISO 13485:2018 Section | Document Section |
+|------------------------|------------------|
+| 8.5.2                  | (All)            |
+| 8.5.3                  | (All)            |
+
+## Summary
+
+This list contains all of our Corrective and Preventive Actions (CAPAs).
+
+## List of CAPAs
+
+* *"Adverse Implications"*: Verifying that the corrective / preventive action does not adversely affect the ability to meet applicable regulatory requirements or the safety and performance of the medical device.
+* *"Verification"*: Documenting proof of implementation of actions taken.
+* *"Effectiveness"*: Review of the effectiveness of corrective / preventive actions taken.
+* *"Root Cause"*: Analyzing the underlying cause that led to the event. Different methodologies can be used, e.g. *5 Why's* (asking 5 times Why? in a row) or *Ishakawa/Fishbone Diagram* (identifying cause categories and sub-causes in a diagram).
+
+| Input Category | CAPA ID | Date Created | CAPA Description | Root Cause | Date Root Cause Analysis Completed | Action (Corrective / Preventive) | Date Actions Defined | Potentially Adverse Implications | Verification | Date of Verification | Effectiveness Evaluation | Date Closed |
+| -------------- | ------- | ------------ | ---------------- | ---------- | ---------------------------------- | -------------------------------- | -------------------- | -------------------------------- | ------------ | -------------------- | ------------------------ | ----------- |
+| Usability feedback | 1 | 01-01-2022 | No contact details provided as part of product information | Missing Test Case for Product Information | 02-01-2022 | New product release incl. contact details; update test cases | 03-01-2022 |  | Release of product version and test case update |  | Number of future complaints related to this issue; review of technical information by Notified Body for completeness |  |
diff --git a/openregulatory/templates/qms/capa/sop-capa.md b/openregulatory/templates/qms/capa/sop-capa.md
new file mode 100644
index 00000000..b8c2b240
--- /dev/null
+++ b/openregulatory/templates/qms/capa/sop-capa.md
@@ -0,0 +1,99 @@
+# SOP Corrective and Preventive Action (CAPA)
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 8.5.1                  | (All)            |
+| 8.5.2                  | (All)            |
+| 8.5.3                  | (All)            |
+
+## Summary
+
+This SOP describes how CAPAs are implemented and tracked.
+
+## Process Steps
+
+### 1. Input for CAPA
+
+Various events may lead to creation of CAPA. Examples include:
+
+ * Product or QMS non-conformities
+ * Customer complaints
+ * Internal bug reports, e.g. by developers
+ * Audit findings
+ * Post-market surveillance findings, including trends
+ * Management review findings, including trends
+
+These inputs may be received from any person inside or outside the company. The QMO is responsible for
+creating the CAPA and tracking its resolution.
+
+CAPAs are tracked in the CAPA list.
+
+| Participants |
+|--------------|
+| QMO          |
+
+| Input                           | Output       |
+|---------------------------------|--------------|
+| Non-conformity, complaint, etc. | CAPA created |
+
+### 2. Decision on Next Steps, Immediate Action
+
+If immediate action is necessary (e.g. product recall, notification of authorities), the QMO consults the Person Responsible for Regulatory Compliance.  Immediate action is carried out without undue delay (see ISO 13485 para. 8.5.2).
+
+In any case, the QMO discusses the next steps with the person closest to the issue, e.g. for software bugs, the
+Head of Software Development.
+
+| Participants                                                                            |
+|-----------------------------------------------------------------------------------------|
+| QMO                                                                                     |
+| Medical Device Safety Officer / Person Responsible for Regulatory Compliance (optional) |
+
+| Input | Output                    |
+|-------|---------------------------|
+| CAPA  | CAPA, updated with action |
+
+### 3. Root Cause Analysis
+
+The QMO coordinates a root cause analysis with the person closest to the issue. The preferred method for this
+is Five Whys. The result is added to the CAPA list.
+
+| Participants                       |
+|------------------------------------|
+| QMO                                |
+| Other people in company (optional) |
+
+| Input | Output                        |
+|-------|-------------------------------|
+| CAPA  | CAPA, updated with root cause |
+
+### 4. Implementation of Action
+
+The QMO coordinates defining and implementing corrective and preventive action. Additionally, the QMO takes
+into account adverse negative implications and verifies that the actions do not adversely affect the ability
+to meet applicable regulatory requirements or the safety and performance of the medical device. Outcomes are
+documented in the CAPA list.
+
+| Participants                       |
+|------------------------------------|
+| QMO                                |
+| Other people in company (optional) |
+
+| Input | Output                         |
+|-------|--------------------------------|
+| CAPA  | CAPA, updated with action plan |
+
+### 5. Verification and Check of Effectiveness
+
+The QMO conducts the verification and effectiveness review of the implemented action. These are defined as
+below. Thereafter, the QMO closes the CAPA.
+
+* Verification: Documenting proof of implementation of actions taken.
+* Effectiveness: Review of the effectiveness of actions taken.
+
+| Participants |
+|--------------|
+| QMO          |
+
+| Input | Output                                                             |
+|-------|--------------------------------------------------------------------|
+| CAPA  | CAPA, updated with verification, effectiveness review, closed date |
diff --git a/openregulatory/templates/qms/document-and-record-control/document-list-dlqms.md b/openregulatory/templates/qms/document-and-record-control/document-list-dlqms.md
new file mode 100644
index 00000000..a1b22f94
--- /dev/null
+++ b/openregulatory/templates/qms/document-and-record-control/document-list-dlqms.md
@@ -0,0 +1,8 @@
+# Document List QMS
+
+> The purpose of this template is to give an idea of the structure. You are much better off not using a word
+> document, but excel / sheets for this.
+
+| Title / Doc-ID                  | Doc Type | Version | Release Date | Last Review | Next Review | Process Owner | Comment |
+|---------------------------------|----------|---------|--------------|-------------|-------------|---------------|---------|
+| SOP-Document and Record Control | SOP      | 1.0     | 15.01.2021   | 15.07.2021  | 15.07.2022  | QMO           |         |
diff --git a/openregulatory/templates/qms/document-and-record-control/sop-document-record-control.md b/openregulatory/templates/qms/document-and-record-control/sop-document-record-control.md
new file mode 100644
index 00000000..0c1e7834
--- /dev/null
+++ b/openregulatory/templates/qms/document-and-record-control/sop-document-record-control.md
@@ -0,0 +1,259 @@
+# SOP Document and Record Control
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 4.2.4                  | (All)            |
+| 4.2.5                  | (All)            |
+
+## Summary
+
+This SOP describes how documents and records are handled. The goal is to understand how documents are
+typically structured and in what states they can be as they move from draft to release. It's similarly
+important to always have the most recent document available at the specified location while ensuring that
+changes to documents can be traced.
+
+## General Considerations
+
+> This whole template assumes that you're using Google Drive and Google Docs for your QMS. If you're using
+> something else, then.. good luck. Just kidding. You need to customize it, of course. There's specialized QMS
+> software out there which makes some of these tasks easier and lots of other tasks harder :)
+> Make sure to describe somewhere (ideally in this first paragraph), in which tool your QMS documents will be managed and stored.
+
+**Documents** are expected to change over time, whereas **records** are created once and not altered
+significantly afterwards.
+
+All documents are written in English.
+
+### Document and Record Labeling
+
+Documents are named according to this schema:
+
+`ASSOCIATED PROCESS-TYPE-NAME`
+
+Where "associated process" can be abbreviated in capital letters and "type" refers to an abbreviation of the
+document type (see below).  "Name" refers to the actual file name. An example would be:
+
+`SWD-SOP-Integrated Software Development`
+
+For released documents, we add a "-a" suffix (as in: approved) to the document name. An example would be:
+
+`SWD-SOP-Integrated Software Development-a`
+
+For archived documents, we add a "-archived_ARCHIVE DATE" suffix to the document name. An example would be:
+
+`SWD-SOP-Integrated Software Development-archived_2021-03-01`
+
+Product records are ideally labeled with a device number and device version; for instance:
+
+`PR1-V1.2-ESW-SWDP-Software Development Plan`
+
+### Document Type Abbreviations
+
+> There probably will be more types in the future when I add more templates. For now, this covers all types of
+> the templates on openregulatory.com.
+
+| Abbreviation | Description                                        |
+|--------------|----------------------------------------------------|
+| AM           | Attachment                                         |
+| LIS          | List                                               |
+| SD           | Supporting Documentation                           |
+| SOP          | Standard Operating Procedure (Process Description) |
+| TPL          | Template                                           |
+
+
+### Retention Periods
+
+QMS documents and records shall be stored for at least 10 years after their archival date.
+
+Technical Documentation shall be stored for at least 10 years after the lifecycle of the respective device has
+ended.
+
+### Review Periods
+
+We review our QMS documents typically once per year to ensure they remain up to date.
+
+Our core and safety processes as defined in the quality management manual must be reviewed at minimum once per
+year.
+
+All other processes and associated documents can be reviewed every three years once they have been reviewed
+before without any findings.
+
+In case of audit findings or related corrective action, it is up to the discretion of the QMO to apply shorter
+review periods (e.g. 6 months).
+
+### QMS Document List
+
+We keep an overview list of all QMS documents, including document type, release date, next review date and
+respective process owners.
+
+## Process Steps
+
+### Handling of Documents
+
+#### 1. Creation of Documents
+
+> This assumes you have three folders in your GDrive: "drafts", "under review" and "released".
+
+All documents are saved in the Quality Management System (QMS) which is a folder in Google Drive.
+
+New documents can be created by anyone in the company in the "drafts" folder. Naming of documents follows the
+general considerations of this SOP (see above). Standard Operating Procedures (SOP) should specify a process
+owner responsible for typically updating, reviewing and releasing all associated documents.
+
+| Participants |
+|--------------|
+| Any employee |
+
+| Input   | Output               |
+|---------|----------------------|
+| Content | New Document (draft) |
+
+#### 2. Documents Ready for Review
+
+Once a document is ready for review, its author moves it to the "under review" folder. Importantly, the author
+selects appropriate reviewers and approvers and notes them at the bottom of the document.
+
+| Participants |
+|--------------|
+| Any employee |
+
+| Input            | Output                  |
+|------------------|-------------------------|
+| Document (draft) | Document (under review) |
+
+#### 3. Review of Documents
+
+The respective reviewer(s) and approver(s) review the document. If changes are required, they create comments
+in the Google Doc and/or suggest changes. If the review is successful, they sign their initials at the bottom
+of the document.
+
+| Participants                                                |
+|-------------------------------------------------------------|
+| Process owner and/or designated reviewer(s) and approver(s) |
+
+| Input                   | Output                       |
+|-------------------------|------------------------------|
+| Document (under review) | Document (review successful) |
+
+#### 4. Release of Documents
+
+The Process Owner moves the document to the "released" folder and assigns "-a" to the document name as
+outlined by the general considerations for document naming.
+
+Access to the "released" folder is restricted to prevent unauthorized changes to released documentation.
+
+The QMO (and, if applicable, the process owner) decide if employee training is required. In general,
+training for minor changes/corrections is not necessary.
+
+| Participants                |
+|-----------------------------|
+| QMO, Process Owner          |
+
+| Input                        | Output              |
+|------------------------------|---------------------|
+| Document (review successful) | Document (released) |
+
+#### 5. Changes to Documents
+
+If changes need to be made to a document, any employee with knowledge about the document and those changes can
+perform them. For that, the currently-released document is copied to the "drafts" folder and edited by the
+employee. After finishing the edit, it moves to the **Document Ready for Review** stage (step 2), following
+the same steps as above.
+
+A QMS change can trigger a substantial change. Before release, it shall be checked whether it may impact the
+organization's process landscape and hence, overall organizational conformity with regulatory
+requirements. The QMO is responsible to evaluate such potentially major changes as part of the Change
+Evaluation List (reference change management process).
+
+
+| Participants      |
+|-------------------|
+| QMO, any employee |
+
+| Input               | Output                |
+|---------------------|-----------------------|
+| Document (released) | Document Copy (draft) |
+
+#### 6. Archiving of Documents
+
+Documents get archived if they become obsolete or a newer released version becomes available. For that, the
+Process Owner removes the "-a" suffix, moves the document to the "archive" folder and assigns a respective
+archiving date following the general considerations for document naming in this SOP. We observe retention
+periods as outlined in this SOP and delete documents as soon as the retention period expired.
+
+| Participants           |
+|------------------------|
+| Process Owner          |
+
+| Input               | Output              |
+|---------------------|---------------------|
+| Document (released) | Document (archived) |
+
+### Handling of Records
+
+#### 1. Creation of Records
+
+We create records as required by our processes. If available, we use templates and checklists for the creation
+of records.  Naming conventions as outlined for documents do not apply. Records should include an author's name
+and the date of creation.
+
+| Participants |
+|--------------|
+| Any employee |
+
+| Input                                      | Output     |
+|--------------------------------------------|------------|
+| Content, Template Document (if applicable) | New Record |
+
+#### 2. Review and Release of Records
+
+Unless specified differently in a template or SOP, records do not typically require a review and release
+process.
+
+| Participants                           |
+|----------------------------------------|
+| Designated reviewer(s) and approver(s) |
+
+| Input                 | Output                     |
+|-----------------------|----------------------------|
+| Record (under review) | Record (review successful) |
+
+#### 3. Storage of Records
+
+Records are not necessarily stored in our QMS folder. They also may reside in other applications as specified
+per respective processes. This is where records are typically stored:
+
+> Add all your tools which stores data which is mentioned in your QMS.
+
+ * *GitHub (Issues, Pull Requests)*
+ * *ZenDesk (Customer Support Tickets)*
+
+
+#### 4. Changes to Records
+
+Records are not significantly altered after creation / release. Where significant changes are required, we
+rather create a new record and archive the old one. Non-substantial changes (e.g. spelling mistakes) are
+considered corrections only, assessed and added on a case-by-case basis.
+
+| Participants |
+|--------------|
+| Any employee |
+
+| Input             | Output           |
+|-------------------|------------------|
+| Record (released) | Record (updated) |
+
+#### 5. Archiving of Records
+
+Records are archived if they become obsolete or a new released version becomes available. For that, the
+process owner moves the records to a respective archiving location. If possible, we follow the general
+considerations for document names and add the archiving date to the record name. We observe retention periods
+as outlined in this SOP and delete records as soon as the retention period expired.
+
+| Participants           |
+|------------------------|
+| Process Owner          |
+
+| Input             | Output            |
+|-------------------|-------------------|
+| Record (released) | Record (archived) |
diff --git a/openregulatory/templates/qms/human-resources/list-of-medical-device-consultants.md b/openregulatory/templates/qms/human-resources/list-of-medical-device-consultants.md
new file mode 100644
index 00000000..784a38e2
--- /dev/null
+++ b/openregulatory/templates/qms/human-resources/list-of-medical-device-consultants.md
@@ -0,0 +1,9 @@
+# List of Medical Device Consultants
+
+> This template is only necessary for German medical device manufacturers as the role of a Medical Device
+> Consultant is specific to German Medical Device Law (§ 83 MPDG / § 31 MPG).
+
+| Full Name | Role / Team / Position       | Medical Device | Date of Last Training | Proof of Training        | Comment |
+|-----------|------------------------------|----------------|-----------------------|--------------------------|---------|
+| Jack Rack | Business Development Manager | (...)          | (...)                 | \<link training record\> | (...)   |
+|           |                              |                |                       |                          |         |
diff --git a/openregulatory/templates/qms/human-resources/list-of-training-documentation.md b/openregulatory/templates/qms/human-resources/list-of-training-documentation.md
new file mode 100644
index 00000000..eca9fb90
--- /dev/null
+++ b/openregulatory/templates/qms/human-resources/list-of-training-documentation.md
@@ -0,0 +1,22 @@
+# List of Training Documentation
+
+> This template is supposed to give you an idea of the structure. Don't use Microsoft Word - this is thought
+> as an Excel / sheets file.
+
+> Also, think of this as two tabs - one for initial and one for continuous training.
+
+## Initial Training
+
+| Employee  | Start of Employment | Job Role      | Training #1: QMS Intro | Date Due   | Date Completed | Effectiveness           | Training #2: Data Privacy | (...) |
+|-----------|---------------------|---------------|------------------------|------------|----------------|-------------------------|---------------------------|-------|
+| Jack Rack | 01.04.2021          | Sales Manager | Applicable             | 15.04.2021 | 14.04.2021     | Confirmed by supervisor | Applicable                |       |
+|           |                     |               |                        |            |                |                         |                           |       |
+
+## Continuous Training
+
+| Name of Training             | Type of Training | Due Date   | Participant #1 | Date Completed | Effectiveness Check        | Participant #2 | Date Completed | (...) |
+|------------------------------|------------------|------------|----------------|----------------|----------------------------|----------------|----------------|-------|
+| Annual Data Privacy Training | Recurring        | 01.04.2021 | Applicable     | 14.04.2021     | Confirmed by questionnaire | Applicable     | 14.04.2021     |       |
+| Code of Conduct              | New SOP          | 01.05.2021 | Applicable     | 03.05.2021     | Confirmed by questionnaire | Applicable     | 03.05.2021     |       |
+| Development Process          | Updated SOP      | 01.05.2021 | N/A            |                |                            | Applicable     | 03.05.2021     |       |
+|                              |                  |            |                |                |                            |                |                |       |
diff --git a/openregulatory/templates/qms/human-resources/sop-human-resources-administration.md b/openregulatory/templates/qms/human-resources/sop-human-resources-administration.md
new file mode 100644
index 00000000..3a4ccea2
--- /dev/null
+++ b/openregulatory/templates/qms/human-resources/sop-human-resources-administration.md
@@ -0,0 +1,185 @@
+| Regulatory Requirement               | Document Section |
+|--------------------------------------|------------------|
+| ISO 13485:2016, sections 6.2 and 7.1 | All              |
+
+## Summary
+
+This SOP provides instructions for the management of personnel in the organization.
+
+It covers the onboarding and offboarding of employees, initial and continuous employee training, and feedback
+processes between supervisors and team members. Thereby, this process shall ensure that the organization
+retains sufficient qualified and motivated staff.
+
+> NOTE: As your organization grows, the following updates to this process can be considered:
+>
+> * *Job descriptions* are formulated as part of a general template and respective records instead of sections
+>   in the quality manual.
+> * Team compositions and hierarchies are outlined as part of an *organizational chart* instead of a table
+>   section in the quality manual.
+> * Design of a *competency matrix* assigning to each role its required training.
+
+## General Considerations
+
+### 1.1 Role Description and Role Assignment
+
+Each employee of the organization is assigned a specific job role for which respective tasks and
+responsibilities as well as the required qualifications are outlined as part of the quality manual. Team
+leaders / supervisors are responsible to ensure that the employees working in their team are trained and
+qualified for the tasks assigned to them. Employee qualification is reviewed against predetermined
+requirements every time before an employee assumes a new task or role.
+
+The QMO, together with an HR Manager, determines the training and qualification requirements per individual
+role that are outlined in the quality manual.
+
+### 1.2 HR File
+
+The organization keeps certain records on every employee, which combined make up the employee’s HR File. These
+include:
+
+* Employee contract and contractual agreements
+* Health insurance documentation
+* Personal identification (e.g., passport scan)
+* Payroll documentation
+* Proof of qualifications (where relevant)
+
+> NOTE: such files are subject to stricter data protection requirements and should be made available to
+> external parties (e.g., auditors, authorities) only upon request. You may want to add instructions on how the
+> files should be protected (for example: access limited to HR staff only).
+
+### 1.3 Training
+
+#### Training Provision and Documentation
+The general aim of the employee training is to ensure the necessary competence of employees to perform their tasks. At minimum, it must ensure that employees are aware of the relevance of their tasks and how they contribute to achieving the quality objectives of the organization (ISO 13485, para. 6.2).
+
+Training may take different forms as deemed most suitable by the instructing employee.
+Training methods may entail:
+
+* Internal or external workshop
+* Media and self-study material (e.g., videos, training documents)
+* Talks and interviews with coworkers or supervisors, supervised working
+
+The QMO should be involved anytime alternative training methods are chosen, in order to ensure appropriate
+training evaluation is guaranteed.
+
+Completed training is documented as part of the organization's training documentation. For external seminars,
+respective training records (e.g., certificates) are saved as part of the HR file (see 1.2.) of each employee
+and should include at minimum: employee name, training method and content, date and signature of an instructor.
+
+> NOTE: in a larger organization, consider creating a template for a training form that employees can use to
+> document their training.
+
+#### Training Effectiveness Evaluation
+
+Completed training is evaluated to ensure the effectiveness of training and that employees are qualified to
+perform their job. For effectiveness evaluation, different methods can be used:
+
+* Test / questionnaire
+* Monitoring job performance
+* External testing
+
+Where no evaluation is included in the training, effectiveness is typically confirmed by the supervisor after completion of training and also documented by the
+QMO as part of the organization's training documentation.
+
+> NOTE: some collaboration tools like Google Workspace allow you to set up questionnaires through which you
+> can test and document(!) your colleague’s self-study success quite easily.
+
+
+#### Role-Specific Training
+
+Training needs may arise from specific roles within the organization:
+
+*Person Responsible for Regulatory Compliance (PRRC)*
+
+Before assuming their role, the PRRC is instructed by the QMO on the tasks and responsibilities of this role
+according to Art. 15 of the Medical Device Regulation. Specifically, the QMO checks if the candidate’s
+qualification meets all the requirements.
+
+*Medical Device Consultants*
+
+Employees speaking to a professional community or instructing on the handling of the organization’s medical
+devices may be subject to Chapter 6 and §83 of the German MPDG. They must receive training on their tasks and
+responsibilities and regulatory requirements according to the law as well as product-specific training that
+should be repeated regularly or based on substantial product changes. The QMO is responsible to keep a list of
+the organization’s trained medical device consultants including the date of their latest training.
+
+## Process Steps
+
+> NOTE: depending on your current processes in place, feel free to add provisions for:
+>
+> * The recruitment of employees (for example: are you using software tools like BambooHR or Personio for the
+>   application process? How do you document hiring decisions? What kind of data protection requirements, like
+>   data deletion periods, must be met?)
+> * Onboarding checklists for HR staff / new employees (including, for example: onboarding meetings a new hire
+>   should complete with relevant coworkers, social insurance registration that HR managers must complete for
+>   new employees)
+
+### 2.1 Onboarding of New Employees
+
+Upon a signed employment contract and before the start date for a new employment, the HR manager is
+responsible to perform administrative onboarding for the new employee, including:
+
+* Creating an HR file for the new employee (see section 1.2)
+* Health and social insurance documentation
+* Payroll administration
+* Ordering required hardware (e.g., laptop, company mobile phone)
+* Granting access rights to relevant software tools (e.g., company messenger, project management
+  tools). Consider: no access should be granted before contractual agreements are signed!
+
+Upon the first day, the direct supervisor or team leader is responsible to ensure that the new employee
+receives and completes initial training. QMO is responsible for determining required QMS training. Completed
+training is documented as part of the list of training documentation. Initial training must be completed within the first week.
+
+|              |                                                             |
+|--------------|-------------------------------------------------------------|
+| Participants | New employee<br>HR Manager<br>Team Lead / Supervisor<br>QMO |
+| Input        | Signed employment contract                                  |
+| Output       | Completed onboarding process                                |
+
+### 2.2 Continuous Training
+
+Besides initial onboarding, new training need may arise from one of the following:
+
+* Annual due date: the QMO may define annually recurring training.
+* Changes in job role: certain job roles require role-specific training (see 1.3).
+* Nonconformities: root cause analysis of CAPAs may reveal a lack of training.
+* Regulatory changes: based on updates to the QM system (e.g., new processes) or to applicable regulation, the
+  QMO may determine further training need.
+
+|              |                                           |
+|--------------|-------------------------------------------|
+| Participants | QMO<br>Employee<br>Team Lead / Supervisor |
+| Input        | Additional training need                  |
+| Output       | Updated training documentation            |
+
+
+### 2.3 Employee Development
+
+At minimum once per year, supervisors schedule meetings with their employees to exchange feedback, to discuss
+the employee’s personal development and also to identify additional training needs required to reach
+development goals.
+
+|              |                                    |
+|--------------|------------------------------------|
+| Participants | Employee<br>Team Lead / Supervisor |
+| Input        | Development interview due          |
+| Output       | Interview records (e.g., protocol)  |
+
+### 2.4 Offboarding of Employees
+
+Upon notification that an employment contract is terminated, the HR Manager is responsible to perform
+administrative offboarding. This includes:
+
+* Timely removal of access rights to software tools and company premise
+* Observing data deletion periods:
+  * Payroll data is deleted 10 years after termination of employment according to German law (§257 HGB).
+  * Administrative data (name, address, title, dates of employment) is deleted 3 years after termination of
+    employment according to German law (§195 BGB).
+  * The employee’s business email account is suspended and deleted 60 days after termination of employment.
+  * All other personal data is deleted immediately after termination of employment.
+  * Where applicable, third-party processors are notified to also delete personal data.
+
+|              |                                                                 |
+|--------------|-----------------------------------------------------------------|
+| Participants | HR Manager                                                      |
+| Input        | Termination of employment                                       |
+| Output       | Removal of access rights<br>Updated documentation: deleted data |
diff --git a/openregulatory/templates/qms/human-resources/training-record.md b/openregulatory/templates/qms/human-resources/training-record.md
new file mode 100644
index 00000000..525f0cd9
--- /dev/null
+++ b/openregulatory/templates/qms/human-resources/training-record.md
@@ -0,0 +1,48 @@
+## 1. General Information
+
+|                  |   |
+|------------------|---|
+| Name of Training |   |
+| Date of Training |   |
+| Training Method  |   |
+| Trainer          |   |
+| Content          |   |
+
+## 2. Participants
+
+| No. | Name | Signature | Successful |
+|-----|------|-----------|------------|
+| 1   |      |           |            |
+| 2   |      |           |            |
+|     |      |           |            |
+
+## 3. Confirmation
+
+Hereby, the training supervisor confirms the successful completion of this training for all participants as
+indicated in the table above.
+
+| Action       | Name | Team / Role | Date | Signature |
+|--------------|------|-------------|------|-----------|
+| Confirmation |      |             |      |           |
+
+## 4. Evaluation
+
+To be applied after training which has no included effectiveness check (e.g. electronic test): assessment of
+effectiveness should be typically carried out by a supervisor. By derogation, a self-assessment is possible,
+provided that no second person can adequately evaluate the effectiveness.
+
+| Action | Name | Team / Role | Date | Signature |
+|--------|------|-------------|------|-----------|
+| Review |      |             |      |           |
+
+| Aspect                                | Objectives (largely) not achieved | Objectives partially achieved | Objectives (largely) achieved | Commentary |
+|---------------------------------------|-----------------------------------|-------------------------------|-------------------------------|------------|
+| Applicability and practical relevance |                                   |                               |                               |            |
+| Comprehensibility                     |                                   |                               |                               |            |
+| Depth                                 |                                   |                               |                               |            |
+
+[ ] The training has sufficiently achieved the objective. No further actions are necessary.
+
+[ ] The training has not sufficiently achieved the objective. The following actions are proposed.
+
+Actions:
diff --git a/openregulatory/templates/qms/management-review/management-review-report.md b/openregulatory/templates/qms/management-review/management-review-report.md
new file mode 100644
index 00000000..c3156a6b
--- /dev/null
+++ b/openregulatory/templates/qms/management-review/management-review-report.md
@@ -0,0 +1,34 @@
+# Management Review Report
+
+> NOTE #1: This template is supposed to give you an idea of the structure. Don't use MS word - this is thought
+> as an excel / sheets file.
+
+> NOTE #2: Think of the sub-sections below as different tabs in your excel sheet.
+
+## Overall Assessment
+
+**Overall QMS Assessment:**
+
+> NOTE: Assess the general adequacy, suitability and efficacy or QM system to comply with regulatory
+> requirements. Also take into account an assessment of the criticality / impact of single processes for
+> product safety. List a summary of measures derived from the review.
+
+|                              |           |
+|------------------------------|-----------|
+| Date of Review               | XYZ (...) |
+| Participants<br>(Name, Role) | XYZ (...) |
+| Signature                    | XYZ (...) |
+
+## Process Assessment
+
+> NOTE: In your excel sheet, you may want to create one tab for every process and include results from
+> previous Management Reviews for comparison.
+
+| SOP                                     | Key Performance Indicator                        | Review Input                 | Management Assessment                              | Improvement Measures | Evaluation of Previous Measures |
+|-----------------------------------------|--------------------------------------------------|------------------------------|----------------------------------------------------|----------------------|---------------------------------|
+| Corrective and Preventive Action (CAPA) | Quick decision of action plan (goal: max. 1week) | Last year: 3 days on average | Process is followed and complies with requirements | None                 | N/A                             |
+| Change Management                       |                                                  |                              |                                                    |                      |                                 |
+| Document and Record Control             |                                                  |                              |                                                    |                      |                                 |
+| Software Development                    |                                                  |                              |                                                    |                      |                                 |
+| Management Review                       |                                                  |                              |                                                    |                      |                                 |
+| (...)                                   |                                                  |                              |                                                    |                      |                                 |
diff --git a/openregulatory/templates/qms/management-review/sop-management-review.md b/openregulatory/templates/qms/management-review/sop-management-review.md
new file mode 100644
index 00000000..3ff4ff90
--- /dev/null
+++ b/openregulatory/templates/qms/management-review/sop-management-review.md
@@ -0,0 +1,114 @@
+| Regulatory Requirement     | Document Section |
+|----------------------------|------------------|
+| ISO 13485:2016 Section 5.6 | All              |
+
+## Summary
+
+This SOP describes how the surveillance of the quality management system shall be conducted to ensure ongoing
+adequacy, suitability and efficacy of organizational processes. The organization regularly conducts a
+Management Review to document the assessment of QMS surveillance outputs and overall compliance with
+regulatory requirements.
+
+## General Considerations
+
+### 1.1. Management Review Input
+
+The organization can use varying key performance indicators (KPIs) to measure processes. At minimum, the
+following data must be collected as input for the Management Review:
+
+* **Status of Measures of Previous Management Reviews**\
+  Input: which measures have been implemented as planned.\
+  Management shall evaluate the effectiveness and efficacy of previous measures.
+* **Audits Results**\
+  Input: findings and measures from internal audits, audits by authorities and Notified Bodies, supplier
+  audits conducted by the organization.
+* **Status of Corrective and Preventive Actions (CAPA)**\
+  Input: summary of nonconformities found and respective actions taken.
+* **Status of Feedback Management and Complaint Handling**\
+  Input: summary of feedback and complaints received and actions taken in response.
+* **Status of Risk Management**\
+  Input: summary of actions taken as part of risk management, e.g. risk mitigation, updates of the risk
+  management report, results from post-market surveillance, etc.
+* **Status of Incident Reporting**\
+  Input: potential incidents that were assessed, incidents that were reported, summary of coordination with
+  supervisory authorities, actions taken as a result.
+* **Status of Applicable Regulation**\
+  Input: published and/or anticipated updates of relevant regulation, including expected implications for
+  the QM system.
+* **Changes to the Quality Management System**\
+  Input: implemented and/or anticipated changes that impact the QM system (and which, ideally, are assessed
+  as part of the Change Evaluation List - for instance, changes to the organizational structure,
+  infrastructure, processes or customer requirements).
+* **Other Key Performance Indicators (KPIs)**\
+  While not every process of the QM system requires a KPI, most processes should be assigned an indicator
+  that allows the assessment of process effectiveness, unless there is a valid explanation for why no KPI
+  is reasonably applicable.
+
+
+### 1.2. Management Review Output
+
+At minimum, the Management Review Report shall provide an assessment of the adequacy, suitability and efficacy
+of the QM system to comply with regulatory requirements. Additionally, process impact on product safety shall
+be critically reviewed.
+
+As part of this process, the Management also reviews the organization’s quality policy, quality objectives and
+the status of previous strategic goals. It defines new strategic goals for the next review period.
+
+> NOTE: this refers to the section of your quality manual where you describe your organization’s process of
+> managing company / team objectives.
+
+Based on findings during the Management Review, the Management may define further measures such as the
+revision of single processes, product changes or the (re-)allocation of resources.
+
+### 1.3. Review Period
+
+The organization shall conduct a Management Review (at least) once per year. Ideally, the review is conducted
+before an external audit (e.g. by a Notified Body) and no sooner than audit reports from internal auditing are
+available.
+
+## Process Steps
+
+### 2.1 Definition of Strategic Goals and Process KPIs
+
+At the beginning of every review period, Management together with the QMO defines key performance indicators
+(KPIs) for QMS processes as well as strategic goals for the company. The strategic goals are based on the
+organization’s quality objectives as defined in the quality manual. The results of this process step are
+communicated to all relevant members of the organization (e.g. process owners).
+
+|              |                                      |
+|--------------|--------------------------------------|
+| Participants | Management, QMO                      |
+| Input        | Quality Policy, Quality Objectives   |
+| Output       | Strategic Goals, Process KPIs        |
+
+### 2.2 Data Collection and Analysis
+
+Every process owner is responsible to track the KPI of their process during the review period and to keep
+records as required by the process.
+
+At the end of a review period, the QMO collects data input from process owners and analyzes the KPI data
+against pre-defined criteria in preparation for the Management Review. The QMO may undertake further
+investigation to identify nonconformities and to provide a preliminary assessment of the adequacy, suitability
+and efficacy of the QM system.
+
+|              |                         |
+|--------------|-------------------------|
+| Participants | QMO, Process Owners     |
+| Input        | KPI records             |
+| Output       | Completed data analysis |
+
+### 2.3 Management Review Report
+
+Management and QMO together discuss the reported input and completed data analysis. The Management is
+responsible to evaluate the results against the pre-defined criteria and formulate an assessment of the
+adequacy, suitability and efficacy of the QM system. Where necessary, the Management defines measures for
+improvement. The results of the Management Review are documented in the Management Review Report.
+
+Finally, the Management sets strategic goals and, where necessary, new or revised process KPIs for the next
+review period. This is communicated again to all relevant members of the organization.
+
+|              |                                                                                     |
+|--------------|-------------------------------------------------------------------------------------|
+| Participants | Management, QMO                                                                     |
+| Input        | Completed data analysis                                                             |
+| Output       | Management Review Report, new or revised KPIs and strategic goals, planned measures |
diff --git a/openregulatory/templates/qms/post-market-surveillance/periodic-safety-update-report.md b/openregulatory/templates/qms/post-market-surveillance/periodic-safety-update-report.md
new file mode 100644
index 00000000..1d278959
--- /dev/null
+++ b/openregulatory/templates/qms/post-market-surveillance/periodic-safety-update-report.md
@@ -0,0 +1,197 @@
+# Periodic Safety Update Report
+
+This report describes product-specific post-market surveillance activity output as outlined in the Post-Market
+Surveillance Plan.
+
+## Product
+
+|                                     |   |
+|-------------------------------------|---|
+| Product Name:                       |   |
+| Unique Device Identification (UDI): |   |
+| Version:                            |   |
+| Surveillance Period:                |   |
+
+
+## 1. Summary
+
+> Note: Highlight which issues around the safety and performance of your device you identified.
+
+## 2. Impact on Clinical Evaluation: Benefit and Performance
+
+**Are the claims made for expected benefits and performance being met?**
+
+( ) Yes ( ) No
+
+If not, reasons for deviation:
+
+## 3. Impact on Risk Management: Risks and Benefits Determination
+
+**The medical device is safe and the risks correspond to the assumptions in the risk management file:**
+
+( ) Yes ( ) No
+
+If not, describe new risks that have been identified:
+
+**Do the clinical benefits of the device outweigh the risks?**
+
+( ) Yes ( ) No
+
+If not, reasons for deviation:
+
+## 4. Results of Post-Market Surveillance Activities
+
+### Market Data
+
+> Describe sales volume of the device, e.g. amount of users and, where practicable, the usage frequency of the device.
+
+### Summary of Incidents and Problems
+
+> Describe incidents that happened with your device and actions taken (e.g. adverse event reports to
+> authorities, field safety notices to customers, field safety actions).
+
+### Observed undesirable side effects
+
+> Describe incidents that happened with your device and actions taken.
+
+| Title | Date | Hazard in Risk Table | Expected Frequency / Severity | Assessment |
+|-------|------|----------------------|-------------------------------|------------|
+|       |      |                      |                               |            |
+
+### List of CAPAs
+
+The following CAPAs resulted from post-market surveillance activities during product lifetime and the
+following CAPAs were initiated during this surveillance period:
+
+### Summary of Customer Complaints and Problems
+
+**Overall Feedback Assessment:**
+
+* According to the device’s post-market surveillance plan, the overall feedback and complaint rate can be deemed acceptable if (...)
+* Feedback data showed (...)
+
+> Note: Summarize the number of customer complaints, predominant subjects of feedback and whether there was
+> anything of importance regarding safety. More specifically, take into account:
+>
+>  * Is the overall complaint rate deemed acceptable and if so, why?
+>  * Based on feedback, have any trends been analyzed and have any corrective measures been taken? What is the status of such actions?
+>  * Has PMS data been compared to occurrence probabilities from risk management?
+
+*Copy this table for every relevant feedback issue that you have analyzed*
+
+|                 |   |
+|-----------------|---|
+| Subject         |   |
+| Feedback Source |   |
+| Date            |   |
+| Root Cause      |   |
+| Assessment      |   |
+
+### SOUP Issues
+
+> Describe anything of relevance you found when going through issue trackers of your SOUP. Also describe
+> whether this leads to any changes, e.g. you could have updated the SOUP to a newer version (and then updated
+> that entry in the SOUP list), or you identified new risks which should be added to the risk table.
+
+*The SOUP List has been updated.*
+
+(Describe significant changes, e.g., new risks, if applicable)
+
+### Post-Market Data of Similar Products
+
+> Note: copy the sections below for every database that you looked into.
+
+#### BfArM Database(s)
+
+Short description of database:
+
+Search keywords: (Insert keywords)
+
+| Subject | Description and Date | Assessment | Applicable (Yes / No) |
+|---------|----------------------|------------|-----------------------|
+|         |                      |            |                       |
+
+#### FDA Database(s)
+
+Short description of database:
+
+Search keywords: (Insert keywords)
+
+| Subject | Description and Date | Assessment | Applicable (Yes / No) |
+|---------|----------------------|------------|-----------------------|
+|         |                      |            |                       |
+
+
+### Summary of Post-Market Clinical Follow-Up Findings
+
+Post-Market Clinical Follow-Up activities were performed following the manufacturer's process for clinical evaluation.
+
+**Main Findings of Post-Market Clinical Follow-Up Activities:**
+
+> Describe the main findings that were derived from your post-market clinical follow-up.
+
+**Status of Post-Market Clinical Follow-Up Activities:**
+
+> Describe or list here which PMCF activities are planned, were adjusted or completed. Include evidence that
+> the post-market surveillance activities are meeting their objectives. Reference the location of the original
+> data and the analysis performed.
+
+### State of Research and Development
+
+#### Market Information on Similar Devices
+
+> Note: Describe any relevant information on similar devices in the market, e.g. clinical studies that started
+> with outcomes that may be applicable to our device.
+
+*Copy this table for every issue that you evaluated.*
+
+|                      |   |
+|----------------------|---|
+| Query                |   |
+| Results (incl. date) |   |
+| Applicable?          |   |
+| Assessment           |   |
+
+#### Scientific Literature
+
+> Note: This chapter should analyze other publications applicable to our product if not considered already as
+> part of the post-market clinical follow-up.
+
+*Copy this section for every issue that you evaluated.*
+
+Short description of database:
+Search keywords: (Insert keywords)
+
+| ID / Title | Description (incl. date) | Assessment | Applicable (Yes / No) |
+|------------|--------------------------|------------|-----------------------|
+|            |                          |            |                       |
+
+### General Updates of Standards and Legislation
+
+> List legislation and standards which were updated in the meantime. E.g. there could be a new version of ISO
+> 13485 which could be relevant for your company.
+
+## 5. Trend Analysis
+
+> Describe trends that you identified according to the metrics and threshold values that were specified in
+> your post-market surveillance plan.
+>
+> For example: during the surveillance period, we received several customer complaints related to product
+> feature XYZ. Malfunctioning of this software component led to XYZ cases of minor injury which was not
+> anticipated. Therefore, we initiated action to do XYZ (ideally, refer here to the listed CAPAs in section 1
+> above).
+
+*Copy this table for every issue that you evaluated.*
+
+|                                |   |
+|--------------------------------|---|
+| Hazard                         |   |
+| Date / Time Span               |   |
+| Occurrence acc. to             |   |
+| Observation                    |   |
+| Probability acc. to risk table |   |
+| Assessment and Actions Taken    |   |
+
+### Updated Post-Market Surveillance Plan
+
+> List updates to Post-Market Surveillance Plan, if applicable
diff --git a/openregulatory/templates/qms/post-market-surveillance/post-market-clinical-follow-up-plan.md b/openregulatory/templates/qms/post-market-surveillance/post-market-clinical-follow-up-plan.md
new file mode 100644
index 00000000..f6981289
--- /dev/null
+++ b/openregulatory/templates/qms/post-market-surveillance/post-market-clinical-follow-up-plan.md
@@ -0,0 +1,78 @@
+# Post-Market Clinical Follow-Up Plan (PMCFP)
+
+This document is used to plan all post-market clinical follow-up activities for the medical device.
+
+## Product
+
+| Product Name        | Version   |
+|---------------------|-----------|
+| (your product name) | (version) |
+
+## Context
+
+> For your orientation, here is guidance documents that may further help you to fill out the template:
+> * MEDDEV Guidance 2.7/1 Rev. 4 on Clinical Evaluation
+> * MEDDEV Guidance 2.12/2 Rev. 2 on Post-Market Clinical Follow-Up
+
+The post-market clinical follow-up plan is compiled along with concluding the clinical evaluation and is based
+on the clinical evaluation report. Following Annex XIV MDR, it specifies the methods used to collect and
+evaluate clinical data with the aim of:
+
+* confirming the safety and performance of the device throughout its product life cycle,
+* identifying previously unknown side-effects and monitoring the identified side-effects and
+  contraindications,
+* identifying and analyzing emergent risks on the basis of factual evidence,
+* ensuring the continued acceptability of the benefit-risk ratio referred to in sections 1 and 9 of annex I
+  MDR, and
+* identifying possible systematic misuse or off-label use of the device, with a view to verifying that the
+  intended purpose is correct.
+
+## Product Post-Market Clinical Follow-Up
+
+### References
+
+The clinical evaluation report outlined the following risk-benefit-profile for the product:
+
+> Current content in the table really just uses random examples for the Apple watch as a (more or less)
+> figurative medical device.
+
+| Risk ID | Residual Risk                       | Benefit ID | Product Benefit                                                            |
+|---------|-------------------------------------|------------|----------------------------------------------------------------------------|
+| #R1     | Inaccurate blood oxygen measurement | #B1        | Increased quality of life through higher awareness for healthy lifestyle   |
+| #R2     | (...)                               | #B2        | Higher likelihood of detecting chronic diseases linked to low blood oxygen |
+|         |                                     |            |                                                                            |
+
+## PMCF Objectives
+
+> In this section, translate each risk and benefit ID from your report above into a specific objective that
+> can be measured. Based on MEDDEV 2.12./2 guidance, you hereby want to express a "formal hypothesis".
+>
+> Entries are again for Apple watch. Another example: if your product is a software to support diagnosis, one
+> of your aims would be to measure a higher sensitivity / specificity of physicians that use your device. The
+> clinical data you collect will support your claimed product benefits at the end of the PMCF interval.
+
+| Risk / Benefit                                                             | PMCF Objective                  |   | ID  |
+|----------------------------------------------------------------------------|---------------------------------|---|-----|
+| Inaccurate blood oxygen measurement                                        | False-high blood oxygen values  |   | #R1 |
+| Inaccurate blood oxygen measurement                                        | False-low blood oxygen values   |   | #R2 |
+| Higher likelihood of detecting chronic diseases linked to low blood oxygen | Higher detection of sleep apnea |   | #B2 |
+|                                                                            |                                 |   |     |
+
+### PMCF Activities
+
+> In this section, describe the methods you will use to collect the data you specified above. Generally: if
+> you claim that your product will somehow improve the patient's well-being - how will you measure that?
+>
+> For example: if your product is based on machine learning, you may want to calibrate and evaluate your model
+> on customer-specific data before they use it in their clinical setting. Results from such evaluation will
+> give an idea of your model's generalizability (your objective).
+>
+> Other examples are: clinical investigations, analysis of retrospective data, structured user feedback
+> analysis (e.g. surveys), etc.
+
+### PMCF Schedule
+
+| PMCF Activity  | ID              | Responsible Role | Due Date |
+|----------------|-----------------|------------------|----------|
+| Clinical trial | #R1, B#2, (...) | CMO              | (...)    |
+|                |                 |                  |          |
diff --git a/openregulatory/templates/qms/post-market-surveillance/post-market-clinical-follow-up-report.md b/openregulatory/templates/qms/post-market-surveillance/post-market-clinical-follow-up-report.md
new file mode 100644
index 00000000..0718823e
--- /dev/null
+++ b/openregulatory/templates/qms/post-market-surveillance/post-market-clinical-follow-up-report.md
@@ -0,0 +1,68 @@
+# Post-Market Clinical Follow-Up Report (PMCFR)
+
+This template is used to document the results of all post-market-clinical-follow-up activities conducted for
+the medical device.
+
+## Product
+
+| Product Name        | Version   |
+|---------------------|-----------|
+| (your product name) | (version) |
+
+## Context
+
+> For your orientation, here is some guidance documents that may further help you to fill out the template:
+> MEDDEV Guidance 2.7/1 Rev. 4 on Clinical Evaluation
+> MEDDEV Guidance 2.12/2 Rev. 2 on Post-Market Clinical Follow-Up
+
+The post-market clinical follow-up report (PMCFR) is compiled at the end of a surveillance interval as
+specified in the post-market clinical follow-up plan (PMCFP) and serves as input for the next update of the
+clinical evaluation. Following Annex XIV MDR, the PMCF is conducted with the aim of:
+
+* confirming the safety and performance of the device throughout its product life cycle,
+* identifying previously unknown side-effects and monitoring the identified side-effects and
+  contraindications,
+* identifying and analyzing emergent risks on the basis of factual evidence,
+* ensuring the continued acceptability of the benefit-risk ratio referred to in sections 1 and 9 of annex I
+  MDR, and
+* identifying possible systematic misuse or off-label use of the device, with a view to verifying that the
+  intended purpose is correct.
+
+## PMCF Objectives
+
+> In this section, basically copy/paste the objectives from your PMCFP.
+
+## PMCF Methods
+
+> In this section, basically copy/paste the methods from your PMFCP.
+
+## Analysis of Clinical Data
+
+> Provide a list of your PMCF activity results. Ideally, divide it into sub-sections per actions taken and
+> conclude if your objectives have been met.
+
+### Implications for Clinical Evaluation
+
+> Discuss if, based on the clinical data you gathered, your device delivered the anticipated benefits and
+> fulfills the performance characteristics you claimed. For orientation: this refers to the 'References'
+> section in your PMCFP.
+
+### Implications for Risk Management
+
+> Discuss if any new risks were identified or if deviations were observed regarding the assumed probability
+> and severity of existing risks. Outline any risk mitigation measures that should be taken or revised.
+
+| Risk | Measures | Responsible Role | Due DAte |
+|------|----------|------------------|----------|
+|      |          |                  |          |
+|      |          |                  |          |
+
+## PMCF Summary
+
+> Highlight the most relevant results and conclusions from your PMCF activities. For example: does the
+> clinical data suggest that the overall benefit-risk-profile of your product should be updated? If things
+> look worse than before, why can it be assumed that your product is still safe?
+
+## Update of Post-Market Clinical Follow-Up
+
+> Describe implications for PMCF activities in the next surveillance interval.
diff --git a/openregulatory/templates/qms/post-market-surveillance/post-market-surveillance-plan.md b/openregulatory/templates/qms/post-market-surveillance/post-market-surveillance-plan.md
new file mode 100644
index 00000000..2baa6d0e
--- /dev/null
+++ b/openregulatory/templates/qms/post-market-surveillance/post-market-surveillance-plan.md
@@ -0,0 +1,162 @@
+# Post-Market Surveillance Plan
+
+This plan describes product-specific post-market surveillance activities. The general process of how to do
+post-market surveillance is described in SOP Post-Market Surveillance. Its outputs are saved to the
+Post-Market Surveillance Report.
+
+## Product
+
+| Product Name            | Version       | Surveillance Period        |
+|-------------------------|---------------|----------------------------|
+| *\<your product name\>* | *\<version\>* | *\<e.g. 10/2020-10/2021\>* |
+
+
+## 1. General Considerations
+
+> Note: Whatever kind of post-market surveillance activities you define for your product, make sure to map at
+> minimum all of these actions required by the MDR to one activity in section 2 below.
+
+According to Annex III section 1.1 (b) MDR, the post-market surveillance plan shall cover:
+
+| MDR Requirement                                                                                                                                                                                                                                                                           | Activity |
+|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------|
+| A proactive and systematic process to collect any information referred to in point (a). The process shall allow a correct characterisation of the performance of the devices and shall also allow a comparison to be made between the device and similar products available on the market |          |
+| Effective and appropriate methods and processes to assess the collected data;                                                                                                                                                                                                             |          |
+| Suitable indicators and threshold values that shall be used in the continuous reassessment of the benefit-risk analysis and of the risk management as referred to in Section 3 of Annex I;                                                                                                |          |
+| Effective and appropriate methods and tools to investigate complaints and analyze market-related experience collected in the field;                                                                                                                                                       |          |
+| Methods and protocols to manage the events subject to the trend report as provided for in Article 88, including the methods and protocols to be used to establish any statistically significant increase in the frequency or severity of incidents as well as the observation period;     |          |
+| Methods and protocols to communicate effectively with competent authorities, notified bodies, economic operators and users;                                                                                                                                                               |          |
+| Reference to procedures to fulfill the manufacturers obligations laid down in Articles 83, 84 and 86;                                                                                                                                                                                      |          |
+| Systematic procedures to identify and initiate appropriate measures including corrective actions;                                                                                                                                                                                         |          |
+| Effective tools to trace and identify devices for which corrective actions might be necessary;                                                                                                                                                                                            |          |
+| A PMCF plan as referred to in Part B of Annex XIV, or a justification as to why a PMCF is not applicable.                                                                                                                                                                                 |          |
+
+## 2. Data Collection Activities
+
+> Note: In the "Metric / Threshold" column there's a placeholder "(define)". Replace this with the metric and
+> threshold you've decided upon.
+
+| Activity                                                                                                     | Assigned To                  | Metric / Threshold | How Often?                    |
+|--------------------------------------------------------------------------------------------------------------|------------------------------|--------------------|-------------------------------|
+| Incident documentation and analysis of undesirable side effects                                              | QMO                          | (define)           | 1/year on Jan 1st             |
+| Assess feedback (customer complaints, sales feedback)                                                        | Head of Product              | (define)           | 1/year on Jan 1st             |
+| Check SOUP for new published issues                                                                          | Head of Software Development | N/A                | 2/year on Jan 1st and Aug 1st |
+| Research data about similar products in the market                                                           | QMO                          | (define)           | 1/year on Jan 1st             |
+| Conduct post-market clinical follow-up activities as planned                                                 | Head of Medical Team         |                    |                               |
+| Research scientific publications                                                                             | Head of Product              |                    |                               |
+| Research updates of standards and legislation                                                                 | QMO                          |                    |                               |
+| Analyze trends, decide on necessary measures and implement them                                              | QMO                          |                    | 1 /year                       |
+| Update risk management file                                                                                  | QMO                          |                    |                               |
+| Compile post-market clinical follow-up report                                                                | Head of Medical Team         |                    |                               |
+| Compile Periodic Safety Update Report                                                                        | Head of Product              |                    |                               |
+| Upload PSUR to Eudamed database                                                                              |                              |                    |                               |
+| Compile post-market surveillance plan and post-market clinical follow-up plan for next surveillance interval |                              |                    |                               |
+
+## 3. Data Collection Categories
+
+At minimum, the information required by the process for post-market surveillance is collected. For (enter
+product name), the following categories of data will be collected  specifically:
+
+### Information about other devices*
+
+ * [BfArM Field Corrective Actions][bfarm-fca]
+   * Keywords:
+   * Filter:
+   * Time span:
+ * [BfArM Recommendations][bfarm-rec]
+   * Keywords:
+   * Time span:
+ * [MHRA][mhra]
+   * Keywords:
+   * Filter:
+   * Time span:
+ * [Swissmedic: List of recalls and other field corrective actions][swissmedic]
+   * Keywords:
+   * Time span:
+ * [FDA Recalls: medical device recalls][fda-recalls]
+   * Keywords:
+   * Time span:
+ * [FDA Maude][fda-maude]
+   * Keywords:
+   * Time span:
+ * SOUP Incident Reports
+   * Go through SOUP list
+   * Research public incident reports of the last (enter time span) months
+
+> Make sure to not just update your clinical evaluation here and enter the same keywords as for the literature review.
+> Also add keywords for the equivalent / similar devices you compare (such as their brand names).
+
+### Other information about similar devices
+
+ * Google News Search
+   * Filter: (define)
+   * Time span:
+ * (...)
+
+### Specialist literature / technical databases
+
+> Note: This chapter should analyze other publications applicable to our product which are not considered
+> already (or typically) as part of the post-market clinical follow-up.
+
+ * Pubmed
+   * Filter: (define)
+   * Time span: last 12 months
+ * (...)
+
+### Serious incidents of our medical device
+
+ * Incident documentation
+   * Was the device involved in any event that caused, directly or indirectly, death of a patient, user or
+     other person or to a serious deterioration in their state of health? Did the company issue a recall of
+     the device?
+   * If so, attach respective documentation (e.g. field safety notices)
+   * Time span:
+
+### Non-serious incidents and undesirable side effects of our own medical device
+
+ * Feedback and customer complaints
+   * Filter: hazard-related feedback, usability issues
+   * Time span:
+
+### Feedback we collect from our partners, users, distributors, importers
+
+ * Feedback and customer complaints
+   * Filter: not hazard-related feedback, feedback on performance, safety or processes
+   * Time span:
+
+The overall complaint rate is deemed acceptable if:
+* Less than 10% of complaints are associated with moderate severity of harm or higher
+* Overall number of complaints does not exceed 10% of total active users
+* (...)
+
+> Note: customize the acceptance criteria for the overall complaint rate to your setup
+
+### Trends
+
+ * Compile a list of trends as described in the section below.
+
+## 4. Trend Analysis
+
+Trend analysis is performed with a focus on undesirable side-effects and non-serious incidents. These will be
+monitored if they impact the benefit-risk ratio in a negative way.
+
+Hazards in the risk table are compared to post-market surveillance results:
+
+ * If post-market surveillance leads to the finding that the estimated **probability** was too low (= event
+   happened more often in post-market surveillance), actions are initiated as described in the SOP Post-Market
+   Surveillance.
+ * If post-market surveillance leads to the finding that the estimated **severity** was too low (= event
+   happened led to more serious harm in post-market surveillance), a CAPA is initiated.
+
+
+<!-- Links -->
+
+[bfarm-fca]: https://www.bfarm.de/SiteGlobals/Forms/Suche/EN/kundeninfo_Filtersuche_Formular_en.html?nn=4527724
+[bfarm-rec]: https://www.bfarm.de/EN/MedicalDevices/RiskInformation/Recommendations/_functions/_node.html
+[mhra]: https://www.gov.uk/drug-device-alerts
+[swissmedic]: https://fsca.swissmedic.ch/mep/
+
+<!-- This is a great link -->
+[fda-recalls]: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res.cfm?start_search=1&event_id=&productdescriptiontxt=&productcode=&IVDProducts=&rootCauseText=&recallstatus=&centerclassificationtypetext=&recallnumber=&postdatefrom=&postdateto=&productshortreasontxt=&firmlegalnam=&PMA_510K_Num=&pnumber=&knumber=&PAGENUM=100
+
+[fda-maude]: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm
diff --git a/openregulatory/templates/qms/post-market-surveillance/sop-post-market-surveillance.md b/openregulatory/templates/qms/post-market-surveillance/sop-post-market-surveillance.md
new file mode 100644
index 00000000..9116c11e
--- /dev/null
+++ b/openregulatory/templates/qms/post-market-surveillance/sop-post-market-surveillance.md
@@ -0,0 +1,118 @@
+# SOP Post-Market Surveillance
+
+## Summary
+
+This SOP describes how Post-Market Surveillance is performed for products. It ensures that new information
+about safety and performance is proactively collected and can be used as input for the risk management,
+clinical evaluation and software development of our products.
+
+## General Considerations
+
+This process is followed for each product separately, meaning that for each product, a Post-Market
+Surveillance Plan and Report are created and continuously updated.
+
+> Note: For class I devices, you could specify a longer update interval, e.g. once every two years.
+> Note: Feel free to assign the responsibility to any other role. It typically makes sense to choose a role
+> that is both close to product development as well as clinical issues.
+
+| Responsibility  | Document Update Interval |
+|-----------------|--------------------------|
+| Product Manager | Once per year            |
+
+> Please also note that according to the Transitional Provisions of Art. 120 MDR, you are required to comply
+> with MDR requirements regarding post-market surveillance (Art. 83 ff.) starting May 2021 even if your
+> product runs on a valid MDD certificate. This basically means to use the new format of a ‘Period Safety
+> Update Report’ (PSUR).
+
+## Process Steps
+
+### 1. Create Post-Market Surveillance Plan
+
+Based on the clinical evaluation and technical documentation, a new Post-Market Surveillance Plan is created
+for a product.
+
+For medical devices of class IIa, post-market surveillance cycles may extend to no longer than two years. For medical devices of classes IIb and III, annual surveillance cycles apply. For devices of class IIa and higher, each surveillance cycle is concluded with the compilation of a periodic safety update report (see below). For class I devices, longer surveillance cycles may be defined.
+
+| Participants    |
+|-----------------|
+| QMO             |
+| Product Manager |
+
+| Input                  | Output                        |
+|------------------------|-------------------------------|
+| Device Description     | Post-Market Surveillance Plan |
+| Clinical Evaluation    |                               |
+| Risk Management Report |                               |
+
+### 2. Conduct Post-Market Surveillance
+
+The Post-Market Surveillance is carried out as described in the Post-Market Surveillance Plan in the defined
+interval.
+
+The responsible employees continuously collect information from all the categories described below and
+enter them into the report template.
+
+At minimum, the following information categories have to be taken into consideration:
+
+ * **Clinical evaluations and PMCF activities:**: Input from Post-Market Clinical Follow-Up activities (see clinical evaluation process and template for the PMCF plan).
+ * **New research and development in the market:** Information regarding similar medical devices and
+   technologies on the market.
+ * **Input from recalls and reportable events:** Recalls, incidents and unintended side effects reported by
+   competitors, similar products and procedures or reported for other devices of our company (e.g. check BfArM
+   / FDA databases as further specified in the post-market surveillance plan; also see vigilance process).
+ * **New or updated norms and standards, directives, regulation and other laws:** Verification if the list of
+   applicable regulations is up to date.
+ * **SOUP:** Verification if SOUP list is up to date.
+ * **Complaints directly reported by customers:** Information gathered through customer feedback and
+   complaints (see process for feedback management).
+ * **Other feedback** collected or reported by sales or marketing staff, distributors, or other stakeholders.
+
+For each part of information, it is assessed whether it is applicable to the company's product. Additionally,
+the severity of impact on device safety and performance is rated on the following scale:
+
+ * **Severe:** Serious injury or death
+ * **Moderate:** Non-serious injury
+ * **Marginal:** Everything else, less than moderate
+
+Depending on the applicability, severity and observed trends of the new information, appropriate actions are
+initiated. The QMO and the Person Responsible for Regulatory Compliance (PRRC) must be consulted in this step, other roles (e.g. medical
+staff) should be involved if needed.
+
+Actions may entail:
+
+ * **Updating the product risk management file**, for example, by adding new risks according to our risk
+   management process, updating occurrence / severity assumptions made for risks we already documented or
+   updating risk mitigation measures in place).
+ * **Initiating a CAPA**, for example, to update processes, training measures or resource allocation.
+ * **Initiating the vigilance process** reporting serious incidents and FSCA to competent authorities.
+ * **Design changes** to the product following the company’s change management and software development process.
+
+| Participants    |
+|-----------------|
+| QMO             |
+| Product Manager |
+
+| Input                                | Output                |
+|--------------------------------------|-----------------------|
+| Post-Market Surveillance Plan        | Evaluated Information |
+| Post-Market Surveillance Information |                       |
+
+### 3. Compile Periodic Safety Update Report
+
+The Product Manager finalizes the Periodic Safety Update Report (PSUR), which is at least reviewed by the
+Person Responsible for Regulatory Compliance (PRRC). The report should contain at least the following information:
+
+ * main findings of post-market surveillance activities throughout the surveillance interval
+ * conclusion regarding implications for the risk management and clinical evaluation of the product, in
+   particular, the overall residual risk and benefit-risk determination
+ * the sales volume of the device, e.g. amount of users and, where practicable, the usage frequency of the
+   device.
+
+| Participants    |
+|-----------------|
+| PRRC            |
+| Product Manager |
+
+| Input                               | Output                        |
+|-------------------------------------|-------------------------------|
+| Collected and evaluated information | Periodic Safety Update Report |
diff --git a/openregulatory/templates/qms/purchasing/list-of-qualified-suppliers.md b/openregulatory/templates/qms/purchasing/list-of-qualified-suppliers.md
new file mode 100644
index 00000000..62ca514c
--- /dev/null
+++ b/openregulatory/templates/qms/purchasing/list-of-qualified-suppliers.md
@@ -0,0 +1,23 @@
+# List of Qualified Suppliers
+
+> NOTE: The purpose of this template is to give an idea of the structure. You are much better off not using a
+> word document but excel / sheets for this. Also, write your categories as columns and suppliers as rows -
+> this template is reversed due to formatting reasons.
+
+| Supplier Documentation            | Supplier #1                 | Supplier #2                 | (...) |
+|-----------------------------------|-----------------------------|-----------------------------|-------|
+| Supplier Name:                    | ABC Medical Content GmbH    | XYZ Medical Content GmbH    |       |
+| Purchase Description:             | Writing Clinical Evaluation | Writing Clinical Evaluation |       |
+| Supplier Status:                  | Approved                    | Blocked                     |       |
+| Quality of Products / Services    | 3                           | 0                           |       |
+| Timeliness / Punctuality          | 3                           | 3                           |       |
+| Cooperation                       | 3                           | 3                           |       |
+| Payment Terms                     | 3                           | 3                           |       |
+| Average Score:                    | 3                           | 1,8                         |       |
+| Date of Last Evaluation:          | 01-04-2021                  | 01-04-2021                  |       |
+| Completed By:                     | Jack Smith (QMO)            | Jack Smith (QMO)            |       |
+| Non-Disclosure Agreement (NDA)    | \<if existing, link here>   | \<if existing, link here>   |       |
+| Supplier Certification            | \<if existing, link here>   | \<if existing, link here>   |       |
+| Quality Assurance Agreement (QAA) | \<if existing, link here>   | \<if existing, link here>   |       |
+| Supplier Auditing                 | \<if existing, link here>   | \<if existing, link here>   |       |
+| Other Measures                    |                             |                             |       |
diff --git a/openregulatory/templates/qms/purchasing/sop-purchasing.md b/openregulatory/templates/qms/purchasing/sop-purchasing.md
new file mode 100644
index 00000000..9b3f58e8
--- /dev/null
+++ b/openregulatory/templates/qms/purchasing/sop-purchasing.md
@@ -0,0 +1,209 @@
+# SOP Purchasing
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 7.4                    | All              |
+
+## Summary
+
+This SOP describes requirements for the purchasing of goods and services by the organization. It includes
+initial supplier evaluation, budget approval and continuous supplier surveillance. It ensures that only
+high-quality goods and services are purchased in order to guarantee the manufacturing of high-quality products
+for own customers.
+
+## General Considerations
+
+### 1.1 Supplier Qualification
+
+Goods and services that can impact the quality of the organization's medical devices are only purchased from
+qualified suppliers.
+
+Initial supplier evaluation is carried out by following the Supplier Evaluation Checklist.
+
+### 1.2 List of Qualified Suppliers
+
+Suppliers which are deemed critical and which underwent initial supplier evaluation are added to the List of
+Qualified Suppliers. The list is also used to document continuous supplier surveillance and the latest
+evaluation status of every supplier.
+
+### 1.3 Supplier Criticality
+
+A supplier is classified as critical:
+
+* If the purchased goods or services could have a direct impact on the safety of the organization's medical
+  devices; OR:
+* If the purchased goods or services could have a direct impact on the performance of the organization's
+  medical devices; OR:
+* If the purchased goods or services could have a direct impact on the regulatory compliance of the
+  organization's medical devices; OR:
+* If the organization is not able to manufacture its medical devices without the supplier's goods or services;
+  AND:
+* If there is no alternative and equivalent supplier for these goods or services.
+
+If a supplier could have an *indirect impact* on the safety, performance or regulatory compliance of the
+organization's medical devices, it is up to the QMO to determine the supplier's criticality on a case-by-case
+basis depending on their impact on product safety and performance.
+
+A supplier is classified as non-critical if the purchased goods or services have no impact on the safety,
+performance or regulatory compliance of the organization's medical devices.
+
+### 1.4 Supplier Evaluation
+
+Suppliers are evaluated according to the evaluation categories described below:
+
+|                              |                                                                                                                                                      |
+|------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Quality of Products/Services | Quality is assessed based on the number of identified nonconforming purchases and reported reclamations, also taking into account delivery.          |
+| Timeliness / Punctuality     | Timeliness is assessed based on the number of delayed purchases.                                                                                     |
+| Cooperation                  | Cooperation is assessed e.g. based on the availability for follow-up questions and responses to complaints.                                          |
+| Payment Terms                | Payment terms are assessed e.g. based on pricing and discounts, payment options, overdue fees and return policies compared to alternative suppliers. |
+
+Suppliers are evaluated along with these categories by assigning a score value to each category. Score values are
+as follows:
+
+* 0: unacceptable
+* 1: moderate
+* 2: good
+* 3: excellent
+
+In order to complete the evaluation, an average score is calculated from all categories. The quality value is
+weighted double.
+
+The overall score results in the following evaluation outcome:
+
+* Average score 2 - 3: supplier can be approved.
+* Average score 1 - 2: supplier can be approved, provided that surveillance measures are in place (see step
+  2.5 of this process).
+* Average score 0 - 1: supplier cannot be approved and is marked as blocked in the List of Qualified Suppliers.
+
+## Process Steps
+
+### 2.1 Preliminary Regulatory Assessment
+
+Before purchasing any product or service, employees are required to check compatibility with the
+organization's quality standards.
+
+Employees therefore first check if the supplier is approved in the List of Qualified Suppliers. If it is
+listed, they can continue with step 2.3.
+
+If the supplier is documented as blocked in the List of Qualified Suppliers, the employee looks for an
+alternative supplier.
+
+If the supplier is not mentioned in the List of Qualified Suppliers, employees need to request regulatory
+approval for the purchase from the QMO. The QMO checks the supplier's criticality, i.e. the impact of its
+goods and services on the quality of the organization's medical devices, by reviewing against the criteria
+described in section 1.3. The QMO can decide that a supplier is obviously uncritical and that no further
+supplier evaluation is needed. If so, the process continues with step 2.3.
+
+If the supplier is not mentioned in the List of Qualified Suppliers and not deemed obviously uncritical, the
+QMO first conducts an initial supplier evaluation.
+
+|              |                                                                                        |
+|--------------|----------------------------------------------------------------------------------------|
+| Participants | Purchasing employee<br>QMO                                                             |
+| Input        | Preliminary regulatory assessment<br>List of Qualified Suppliers<br>Supplier Checklist |
+| Output       | Regulatory approval for purchase<br>or: need for initial supplier evaluation           |
+
+### 2.2 Initial Supplier Evaluation
+
+The QMO conducts the initial supplier evaluation by completing the Supplier Checklist. They can therefore
+request additional information from the supplier. Only the QMO decides on the approval of a critical supplier.
+
+If the supplier is deemed critical and the initial supplier evaluation is completed successfully, the supplier
+is added to the List of Qualified Suppliers and the process continues with the next step. Based on the
+supplier's criticality for the quality of the organization's medical devices, the QMO may define additional
+measures for supplier surveillance which are also documented as part of the List of Qualified Suppliers.
+
+If the supplier is deemed critical and the evaluation is unsuccessful (meaning, the supplier cannot be
+qualified for purchasing), the supplier is also added to the List of Qualified Suppliers, but marked as
+blocked. In this case, the order cannot be placed and the employee looks for an alternative supplier.
+
+Blocked suppliers can be approved by repeating this process step and conducting a new supplier evaluation.
+
+|              |                                                                                             |
+|--------------|---------------------------------------------------------------------------------------------|
+| Participants | QMO                                                                                         |
+| Input        | Purchase need<br>List of Qualified Suppliers                                                |
+| Output       | Completed supplier evaluation<br>Updated List of Qualified Suppliers<br>Regulatory approval |
+
+### 2.3 Budget Approval
+
+The employee requests their supervisor for budget approval for the respective purchase. The supervisor reviews
+the purchasing costs against the organization's budget plan and approves or denies the request. Upon approval,
+the employee places the order.
+
+|              |                                               |
+|--------------|-----------------------------------------------|
+| Participants | Purchasing employee<br>Supervisor             |
+| Input        | Documented regulatory approval                |
+| Output       | Documented budget approval<br>Order placement |
+
+### 2.4 Verification
+
+The purchasing employee verifies that the received services or goods match the order and fulfill expected
+quality standards.
+
+In case sub-standard quality or in any other way nonconforming services or goods, the QMO is notified to
+document the purchase's effect on continuous supplier evaluation (next step). A complaint is sent to the
+supplier and defective products are returned if applicable.
+
+Invoices and receipts are attached to expense records and archived accordingly.
+
+|              |                                                                                                                          |
+|--------------|--------------------------------------------------------------------------------------------------------------------------|
+| Participants | Purchasing employee<br>QMO                                                                                               |
+| Input        | Received services or goods                                                                                               |
+| Output       | Archived reclamation records (if applicable)<br>Updated List of Qualified Suppliers (if necessary)<br>Invoices processed |
+
+### 2.5 Supplier Surveillance
+
+> NOTE: for class II or higher, the annual re-evaluation of suppliers should be completed prior to the
+> Management Review.
+
+The QMO can decide to undertake various surveillance measures such as:
+
+* **Supplier Certification**: a supplier can be requested to provide valid and ongoing certification as
+  proof of its quality management system's efficacy. In this case, the QMO keeps a copy of the current
+  supplier certificates with the organization's QM records. The validity of supplier certification is checked
+  at least once per year as part of the annual supplier evaluation.
+* **Quality Assurance Agreement (QAA)**: a supplier can be requested to sign a QAA as a commitment to specific
+  quality assurance measures.
+* **Supplier Audits**: supplier audits and site visits can be requested where previous supplier documentation
+  (records, certification) did not establish sufficient objective evidence of a supplier's QM system efficacy
+  and compliance. The QMO is responsible to conduct supplier audits. As part of conducting a supplier audit,
+  an audit plan and audit report are created following the organization's process for Internal
+  Auditing. Additionally, the QMO may decide to set up a continuous audit program for the supplier.
+
+#### 2.5.1 Continuous Supplier Surveillance
+
+Supplier evaluations are updated continuously in the context of every new purchase, but at minimum once per
+year. Surveillance measures are carried out continuously as considered appropriate and documented in the List
+of Qualified Suppliers.
+
+Any new information about a supplier can lead to an update of the supplier's evaluation status. Following a
+decrease in a supplier's evaluation status, the QMO can decide over appropriate measures, such as opening a
+CAPA, further surveillance measures or blocking a supplier in case of a significant decrease in quality
+standards. Opening a CAPA is always required in case of a decrease by one grade according to the evaluation
+criteria outlined in step 1.3.
+
+|              |                                     |
+|--------------|-------------------------------------|
+| Participants | QMO                                 |
+| Input        | New supplier records                |
+| Output       | Updated List of Qualified Suppliers |
+
+#### 2.5.2 Annual Supplier Evaluation
+
+At minimum once per year, the QMO reviews all available information (incl. public records such as complaints,
+ratings, certificates) to update the evaluation status of suppliers listed in the List of Qualified Suppliers.
+
+Following a decrease in a supplier's evaluation status, the QMO can decide over appropriate measures, such as
+opening a CAPA, further surveillance measures or blocking a supplier in case of a significant decrease in
+quality standards. Opening a CAPA is always required in case of a decrease by one grade according to the
+evaluation criteria outlined in step 1.3.
+
+|              |                                                 |
+|--------------|-------------------------------------------------|
+| Participants | QMO                                             |
+| Input        | Supplier records<br>List of Qualified Suppliers |
+| Output       | Updated List of Qualified Suppliers             |
diff --git a/openregulatory/templates/qms/purchasing/supplier-checklist.md b/openregulatory/templates/qms/purchasing/supplier-checklist.md
new file mode 100644
index 00000000..5c938c2f
--- /dev/null
+++ b/openregulatory/templates/qms/purchasing/supplier-checklist.md
@@ -0,0 +1,89 @@
+# Supplier Checklist
+
+#### Scope / Purpose
+
+This checklist is completed every time an initial supplier evaluation is carried out or if a blocked supplier
+is evaluated again for approval.
+
+## 1. General Supplier Information
+
+| Company Name                                  | OpenReg GmbH                                                                 |
+|-----------------------------------------------|------------------------------------------------------------------------------|
+| Address:                                      | c/o Factory Works GmbH<br>Rheinsberger Str. 76/77<br>10115 Berlin<br>Germany |
+| Point of Contact<br>(job role, email, phone): | (...)                                                                        |
+
+## 2. Purchase Description
+
+> NOTE: enter here a description of the goods and services the organization intends to typically purchase from
+> this supplier.
+
+## 3. Supplier Criticality
+
+| Criticality Criteria                                                                                                                   | Yes / No | Explanation / Commentary |
+|----------------------------------------------------------------------------------------------------------------------------------------|----------|--------------------------|
+| (1.) Could the purchased goods or services have a direct impact on the safety of the organization's medical devices?                   |          |                          |
+| (2.) Could the purchased goods or services have an indirect impact on the safety of the organization's medical devices?                |          |                          |
+| (3.) Could the purchased goods or services have a direct impact on the performance of the organization's medical devices?              |          |                          |
+| (4.) Could the purchased goods or services have an indirect impact on the performance of the organization's medical devices?           |          |                          |
+| (5.) Could the purchased goods or services have a direct impact on the regulatory compliance of the organization's medical devices?    |          |                          |
+| (6.) Could the purchased goods or services have an indirect impact on the regulatory compliance of the organization's medical devices? |          |                          |
+| (7.) Is the organization not able to manufacture medical devices without the supplier's goods or services?                                 |          |                          |
+| (8.) Is there no alternative and equivalent supplier for these goods or services?                                                      |          |                          |
+
+* A supplier is classified as **critical** if one of the questions (1.) or (3.) or (5.), or both (7.) and (8.) are answered with YES.
+* A supplier is classified as **non-critical** if all the questions (1.) and (3.) and (5.) are answered with NO.
+* The QMO decides over criticality on a case-by-case basis, if the questions (1.) and (3.) and (5.) and both (7.) and (8.) are answered with NO, but one of the questions on indirect impact (2, 4, 6) are answered with YES.
+
+**Assessment of Criticality:** \<enter here\>
+
+(The assessment result is added to the List of Qualified Suppliers)
+
+## 4. Supplier Evaluation
+
+| Evaluation Criteria          | Score | Explanation / Commentary |
+|------------------------------|-------|--------------------------|
+| Quality of Products/Services |       |                          |
+| Timeliness / Punctuality     |       |                          |
+| Cooperation                  |       |                          |
+| Payment Terms                |       |                          |
+
+Average score:
+
+Provisions for supplier evaluation and further information can be found in step 1.4 of the organization's supplier process.
+
+Additional evaluation criteria can be used to evaluate the suppliers:
+
+| Further Criteria                                                                                                                               | Yes / No | Explanation / Commentary     |
+|------------------------------------------------------------------------------------------------------------------------------------------------|----------|------------------------------|
+| Is there a non-disclosure agreement (NDA) in place between the supplier and our organization?                                                  |          |                              |
+| Does the supplier have a certified management system in place?                                                                                   |          | \<e.g. ISO 9001, ISO 13485\> |
+| Does the supplier conduct quality reviews before shipment?                                                                                     |          |                              |
+| Does the supplier have a system for traceability established?                                                                                  |          |                              |
+| Does the supplier have a procedure for the handling of nonconforming products in place?                                                        |          |                              |
+| Does the supplier have a procedure for the corrective and preventive actions in place?                                                         |          |                              |
+| Does the supplier have a procedure in place to notify customers of changes?                                                                    |          |                              |
+| Does the supplier further subcontract the services/products concerned and does the supplier have its own supplier evaluation process in place? |          |                              |
+
+**Additional supplier information / description:**
+
+\<enter additional information\>
+
+| Final Evaluation Result                                                | Yes / No | Explanation / Commentary |
+|------------------------------------------------------------------------|----------|--------------------------|
+| Does the supplier comply with the organization's quality requirements? |          |                          |
+
+(The evaluation result is added to the List of Qualified Suppliers)
+
+|                          |                             |
+|--------------------------|-----------------------------|
+| Evaluation Completed By: | \<enter name and job role\> |
+| Date Completed:          | \<enter date\>              |
+
+## 5. Surveillance Measures
+
+| Surveillance Measures                                                  | Yes / No | Explanation / Commentary |
+|------------------------------------------------------------------------|----------|--------------------------|
+| Is the supplier required to provide proof of certification?            |          |                          |
+| Is the supplier required to enter a quality assurance agreement (QAA)? |          |                          |
+| Is the supplier required to agree to a supplier audit program?         |          |                          |
+| Are any other supplier surveillance measures required?                 |          |                          |
diff --git a/openregulatory/templates/qms/quality-manual-policy-objectives.md b/openregulatory/templates/qms/quality-manual-policy-objectives.md
new file mode 100644
index 00000000..8d327020
--- /dev/null
+++ b/openregulatory/templates/qms/quality-manual-policy-objectives.md
@@ -0,0 +1,131 @@
+# Quality Manual, Policy and Objectives
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 4.1.1                  | 1.               |
+| 4.1.2                  | 4.               |
+| 4.2.1 b)               | (All)            |
+| 4.2.2                  | (All)            |
+| 5.3                    | 2.               |
+| 5.4.1                  | 2.               |
+
+## Summary
+
+The Quality Manual describes the scope of the Quality Management System, its documented procedures and a
+description of their interactions.
+
+## 1. Scope
+
+The QMS described in this Quality Manual applies to all products of *\<your company name\>*.
+
+### Role of Company
+
+> Other roles besides manufacturer are: Authorized representative, distributor.
+
+*\<your company name\>* is a manufacturer of Medical Devices.
+
+### Applicable Standards
+
+> Remove either the MDD or MDR entry, depending on which you're complying with (MDD will only be possible
+> until May 2021, afterwards it's only MDR).
+
+The following table only gives an overview of the most relevant regulation and standards. For a comprehensive
+overview, see the list of applicable standards (reference here).
+
+| Standard / Regulation / Law | Why Applicable?                                           |
+|-----------------------------|-----------------------------------------------------------|
+| MDD (93/42/EEC)             | Directive for all Medical Device Manufacturers in the EU  |
+| MDR (2017/745/              | Regulation for all Medical Device Manufacturers in the EU |
+| ISO 13485:2016              | QMS required by essential requirements of MDD/MDR         |
+| ISO 14971:2019              | Risk management for medical devices                       |
+| IEC 62304:2006              | Software development for medical devices                  |
+| IEC 62366-1:2015            | Usability evaluation for medical devices                  |
+
+
+### Exclusions
+
+The following sections of ISO 13485:2016 will be excluded due to the product being stand-alone software:
+
+ * 6.4.2 Contamination control
+ * 7.5.2 Cleanliness of product
+ * 7.5.5 Particular requirements for sterile medical devices
+ * 7.5.7 Particular requirements for validation of processes for sterilization and sterile barrier systems
+ * 7.5.9.2 Particular requirements for implantable medical devices
+
+## 2. Quality Policy & Objectives
+
+### Quality Policy
+
+> Describe what your company is about, specifically, its mission and things which are important for it. Maybe
+> you're developing software for patients with a certain disease and your goal is to improve their lives.
+
+### Quality Objectives
+
+> Whatever policy you outlined above, now you need to make it measurable by defining objectives which can be
+> tracked. Those objectives should not (only) refer to the quality of your devices but the quality of your QMS and the overall work of your organization. > Typical examples are: hiring excellence in staff, providing best-of-class device performance, high standards of customer satisfaction, etc.
+> In a next step (see short-term goals), those are narrowed down to concrete measures like for example the monthly number of user complaints.
+
+### Short-Term Goals
+
+> How does your team track its goals? Your auditors want to see how your quality objectives translate into
+> your daily work. You should formulate strategic goals for your company that are somewhat related to your
+> quality goals and which are tracked at least on an annual basis. Do you already have a goal-oriented system in
+> place to track your team’s work? Even better: align business and quality goals and describe your system
+> here.
+
+## 3. Roles
+
+> Describe the roles of the people in your company. Typically this is done by drawing an organigram (you could
+> use draw.io for that). Or, you just use a table like below.
+
+| Role            | People                    |
+|-----------------|---------------------------|
+| CEO             | Steve Jobs                |
+| CTO             | Steve Wozniak             |
+| Product Manager | Ada Lovelace              |
+| QMO             | Oliver Eidel              |
+
+All C-level roles (CEO, CTO, CMO) are referred to as the Management. Management is generally responsible to
+define responsibilities and authorities, to define and communicate Quality Policy and Goals and to ensure that
+the whole organization is oriented towards them.
+
+> See ISO 13485, para. 5.1, para. 5.5.1
+
+The Quality Management Officer (QMO) is responsible to:
+
+* ensure that processes needed for the company’s quality management system are documented
+* report to top management on the effectiveness of the quality management system and any need for improvement
+* ensure the promotion of awareness of applicable regulatory requirements and QMS requirements throughout the
+  organization.
+
+> See ISO 13485, para. 5.1, para. 5.5.2
+
+Person Responsible for Regulatory Compliance (PRRC)
+Responsibilities of the PRRC are in accordance with Art. 15 MDR as follows:
+* Ensure (review / release) the conformity of the devices is appropriately checked in accordance with the QMS before a device is released (also see Art. 10 Para. 9 MDR)
+* Ensure (review / release) that the technical documentation and the EU declaration of conformity are drawn up and kept up-to-date for all medical devices (also see Art. 10 Para. 4 and Art. 6 MDR)
+* Ensure (review / release) that obligations for post-market surveillance are complied with in accordance with Art. 10 Para. 10 MDR
+* Ensure (review / release) that the reporting obligations of Articles 87 to 91 MDR are fulfilled (FSCA / incidents, also see Art. 10 Para. 13 MDR)
+* Ensure that, in the case of investigational devices, the statement referred to in Section 4.1 of Chapter II of Annex XV MDR is issued.
+
+The PRRC shall not be subjected to Management instructions while carrying out his/her responsibilities specified above. His/her tasks may be delegated to other roles as long as it is ensured that final responsibility stays with the PRRC. She or he has the power and authority to represent the company in the scope of his/her responsibilities, e.g. in communicating with state authorities.
+
+Required qualification for this role:
+* Fluent in English language
+* Knowledge of the role and responsibilities of a ‘Person Responsible for Regulatory Compliance’ according to Art. 15 MDR
+* Higher education degree in law, medicine, pharmacology or engineering
+OR: four years of professional experience in the fields of quality management and regulatory affairs
+* At minimum one year of professional experience in the fields of quality management and regulatory affairs
+
+## 4. Processes
+
+> List all your SOPs here. This list is currently incomplete as many SOPs are company-specific. You will have
+> to complete it yourself - good luck!
+
+| SOP                                  | Process Category |
+|--------------------------------------|------------------|
+| SOP Corrective and Preventive Action | Core             |
+| SOP Document and Record Control      | Core             |
+| SOP Integrated Software Development  | Core             |
+| SOP Post-Market Surveillance         | Support          |
+| SOP Software Validation              | Support          |
diff --git a/openregulatory/templates/qms/software-validation/software-list.md b/openregulatory/templates/qms/software-validation/software-list.md
new file mode 100644
index 00000000..e6dfb9a8
--- /dev/null
+++ b/openregulatory/templates/qms/software-validation/software-list.md
@@ -0,0 +1,13 @@
+# Software List
+
+> List all your software which you use either in your Quality Management System or as part of your product
+> development. Typically, those include Slack, GitHub, your IDE (e.g., IntelliJ) and programming libraries
+> which you (only) use during development.
+>
+> Libraries which you include in your product (i.e., which are deployed with it) don't belong here. They belong
+> in the SOUP list.
+
+| ID | Name          | Manufacturer     | Bug tracker URL                            | Needs validation? | Next validation | Last validation | Decommissioning |
+|----|---------------|------------------|--------------------------------------------|-------------------|-----------------|-----------------|-----------------|
+| 1  | GitHub        | GitHub, Inc.     |                                            | yes               | 2020-05-17      |                 |                 |
+| 2  | IntelliJ IDEA | JetBrains s.r.o. | https://youtrack.jetbrains.com/issues/IDEA | yes               | 2020-05-17      |                 |                 |
diff --git a/openregulatory/templates/qms/software-validation/software-validation-form.md b/openregulatory/templates/qms/software-validation/software-validation-form.md
new file mode 100644
index 00000000..9baf6383
--- /dev/null
+++ b/openregulatory/templates/qms/software-validation/software-validation-form.md
@@ -0,0 +1,154 @@
+# \<Software Title\> - Software Validation Form
+
+## 1. Information about the Software
+
+|           |                                          |
+|-----------|------------------------------------------|
+| QMS ID    | \<ID\>                                   |
+| Name      | \<Name\>                                 |
+| Version   | \<x.x.x\>                                |
+| Location  | \<url\>                                  |
+| Processes | \<processes in which this tool is used\> |
+
+## 2. Intended Use and Use Context
+
+> Describe intended use and usage context (e.g. automation, testing, control, altering). Include technical and
+> usage requirements that the system shall fulfill.
+
+## 3. Quality Relevance
+
+*Rate these aspects with yes (y) or no (n). If any of these aspects are rated as yes, the system is quality
+relevant and should be validated.*
+
+| **Criterion**                                                                                                                         | **Y/N** |
+|---------------------------------------------------------------------------------------------------------------------------------------|---------|
+| Is the system used in one or more processes that steer the QMS?                                                                       |         |
+| Could the conformity of the organization’s medical devices be affected if the system does not work according to its specifications?   |         |
+| Could risks arise for patients, users, third parties or the organization if the system does not work according to its specifications? |         |
+| Does the software generate or manage data / records that are relevant to the QMS or medical device approval by authorities?           |         |
+| Is the software used to generate electronic signatures on documents or records required by the QMS and/or state authorities?          |         |
+
+## 4. General Assessment
+
+### 4.1 Software Category
+
+* Infrastructure software (e.g. operating systems, databases, office applications, antivirus, network
+  management software) (GAMP category 1)
+* Non-configurable software (GAMP category 3)
+* Configurable software (GAMP category 4)
+* Custom (self-developed) software (GAMP category 5)
+
+### 4.2 Risk Assessment
+
+**List of Risks:**
+
+* \<list of risks\>
+
+**List of Risk Mitigation Measures (if necessary):**
+
+* \<list possible risk mitigation measures\>
+
+### 4.3 Criticality and Review Schedule
+
+*Refer to section 10 for descriptions of the criticality classifications. If a software is not highly critical
+and widely adopted / commonly used, it can be continuously re-validated during use.*
+
+* **Low** (review upon major changes)
+* **Moderate** (review every year)
+* **High** (review every 6 months)
+
+## 5. Validation Plan
+
+### 5.1 Participants
+
+| Role | Name | Task(s) |
+|------|------|---------|
+|      |      |         |
+
+### 5.2 Test Environment
+
+* Software tool accessed with \<Windows 10 20H2 on Google Chrome 88.0.4324.150\>
+* Reference User Manual
+
+### 5.3 Testing Procedure
+
+* Run software system on sample data
+
+## 6. Validation Report and Requirements
+
+### 6.1 Acceptance Criteria
+
+The software is approved for use if it is validated successfully and works as expected.
+
+### 6.2 Validation of Usage Requirements
+
+| ID | Expected                                                       | Result                                                                        | Pass? |
+|----|----------------------------------------------------------------|-------------------------------------------------------------------------------|-------|
+| U1 | e.g. "A radiologist can log in with their email and password." | "Login with correct email and password grants access to the annotation tool." | yes   |
+|    |                                                                |                                                                               |       |
+
+### 6.3 Validation of Technical Requirements
+
+| ID | Expected                                                           | Result                                             | Pass? |
+|----|--------------------------------------------------------------------|----------------------------------------------------|-------|
+| T1 | e.g. "Execute correctly in the specified runtime (Google Chrome)." | "The application runs correctly in Google Chrome." | yes   |
+|    |                                                                    |                                                    |       |
+
+### 6.4 Summary of Validation
+
+| Type                   | Total | Pass | Fail |
+|------------------------|-------|------|------|
+| Usage Requirements     | 1     | 1    | 0    |
+| Technical Requirements | 1     | 1    | 0    |
+
+### 6.5 Conclusion
+
+Approving the software for use is recommended due to the acceptance criteria being fulfilled completely.
+
+## 7. Proof of Validation
+
+> You can optionally insert screenshots for proof of validation. Strictly speaking, this is not a hard
+> requirement by the standards but it's nice to show when you're being audited.
+
+|    |                       |
+|----|-----------------------|
+| U1 | \<insert screenshot\> |
+| T1 | \<insert screenshot\> |
+
+## 8. Approval and Release
+
+| **Date of Approval** | **Name of Approver** |
+|----------------------|----------------------|
+| \<date\>             | \<name\>             |
+
+## 9. History
+
+| Date | Name | Activity             |
+|------|------|----------------------|
+|      |      | \<Initial Approval\> |
+
+## 10. Annex: Additional Information for Criticality Classification
+
+**GAMP Implications**
+
+* GAMP 5 always leads to "high" software criticality
+* GAMP 4 always leads to a "high" or "moderate" software criticality, depending on further risk assessment in step 4.2
+* GAMP 1 and 3 typically leads to a "low" or "moderate" software criticality, depending on further risk assessment in step 4.2
+
+**Criticality High**
+
+* A software failure can lead to physical harm requiring medical intervention
+* Software controls parameters or data that are essential during product release
+* Software manages data relevant for clinical evaluation or product approval
+* Software manages data from which conclusions about incident messages or recall actions are drawn
+
+**Criticality Moderate**
+
+* A software failure can lead to physical damage requiring medical intervention
+* Software administers documents whose loss endangers the certification
+* Software controls intermediate results in the product realization, which are revealed in later steps by
+  other processes
+
+**Criticality Low**
+
+* Software manages documents that play a role in the QM system, and whose loss would lead to an audit variance
diff --git a/openregulatory/templates/qms/software-validation/sop-software-validation.md b/openregulatory/templates/qms/software-validation/sop-software-validation.md
new file mode 100644
index 00000000..f9b7b097
--- /dev/null
+++ b/openregulatory/templates/qms/software-validation/sop-software-validation.md
@@ -0,0 +1,120 @@
+# SOP Software Validation
+
+## Summary
+
+This SOP ensures that the organization only works with validated computer/software systems to avoid erroneous
+systems affecting the safety and performance of its medical devices. The process outlines requirements for
+validation before use.
+
+|                           |                                                                      |
+|---------------------------|----------------------------------------------------------------------|
+| **Process Owner**         | QMO                                                                  |
+| **Regulatory References** | ISO 13485:2016 Sec. 4.1.6 and 6.3 and 7.6<br>IEC 62304:2016 Sec. 9.8 |
+
+## Process Steps
+
+### 1.1 Collecting Information and Preliminary Assessment
+
+ * Employee notifies QMO of the new system and provides the minimum information required for preliminary
+   assessment, such as intended use description and preliminary risk estimation.
+ * QMO documents the intended use and determines whether the system is relevant for the QMS or the
+   organization’s medical devices as part of the computerized system validation form.
+ * If quality-relevant: continue to fill out the computerized system validation form (assessing criticality
+   and risks).
+ * If not quality-relevant: document the system in the list of computerized systems and release the software
+   system for use.
+
+| Responsible                                    |
+|------------------------------------------------|
+| Employee intending to work with the new system |
+| QMO                                            |
+
+| Input                        | Output                          |
+|------------------------------|---------------------------------|
+| Information about the system | Preliminary Software Assessment |
+| Software Validation Form     |                                 |
+| List of Softwares            |                                 |
+
+
+### 1.2 Plan Validation
+
+ * QMO continues to fill out the computerized system validation form by planning the validation and
+   documenting the requirements for expected validation results.
+
+| Responsible |
+|-------------|
+| QMO         |
+
+| Input                    | Output                           |
+|--------------------------|----------------------------------|
+| Software Validation Form | Updated Software Validation Form |
+
+### 1.3 Perform Validation
+
+ * Perform the validation based on the validation plan and fill out the validation report as part of the
+   software validation form.
+ * Where appropriate, save additional proof of validation (e.g. screenshots) and add them to the validation
+   report.
+
+| Responsible                      |
+|----------------------------------|
+| Employee working with the system |
+
+| Input                    | Output                           |
+|--------------------------|----------------------------------|
+| Software Validation Form | Updated Software Validation Form |
+
+
+### 1.4 Release
+
+If validation was not successful:
+
+ * Document the validation results in the list of computerized systems and classify the system as "blocked" /
+   "not released for use".
+
+If validation was successful:
+
+ * Document the validation results and sign the validation report as part of the computerized system
+   validation form.
+ * Release the computerized system by adding it to the list of computerized systems.
+ * Inform relevant staff about the approval of the system.
+
+| Responsible |
+|-------------|
+| QMO         |
+
+| Input                    | Output                             |
+|--------------------------|------------------------------------|
+| Software Validation Form | Completed Software Validation Form |
+| Software List            | Updated List of Software           |
+|                          | Notification sent                  |
+
+### 1.5 Monitoring of Softwares
+
+ * User feedback and error reports by developers are monitored for relevant occurrences that may affect the
+   organization or its medical devices.
+ * New version updates are implemented and the list of computerized systems is updated accordingly. If
+   necessary, a revalidation is carried out.
+
+| Responsible                                                |
+|------------------------------------------------------------|
+| QMO in collaboration with employee working with the system |
+
+| Input                               | Output                                                       |
+|-------------------------------------|--------------------------------------------------------------|
+| Error reports by users / developers | Updated List of Software                                     |
+|                                     | If required: new record of Softwares Validation Form created |
+
+### 1.6 Decommissioning of Software
+
+ * In case it is decided to decommission a computerized system, evaluate possible effects and document the
+   actions in the List of Software.
+
+| Responsible |
+|-------------|
+| QMO         |
+
+| Input                    | Output                   |
+|--------------------------|--------------------------|
+| Software Validation Form | Updated List of Software |
+| Software List            |                          |
diff --git a/openregulatory/templates/qms/sop-feedback-management.md b/openregulatory/templates/qms/sop-feedback-management.md
new file mode 100644
index 00000000..c7ca700a
--- /dev/null
+++ b/openregulatory/templates/qms/sop-feedback-management.md
@@ -0,0 +1,130 @@
+# SOP Feedback Management and Customer Complaints
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 8.2.1.                 | All              |
+| 8.2.2.                 | All              |
+
+| IEC 62304:2006 Section | Document Section |
+|------------------------|------------------|
+| 6.2.1                  | All              |
+
+## Summary
+
+This SOP describes how to respond to feedback and complaints.
+
+## General Considerations
+
+> In this section, provide general information about how you intend to set up your company's feedback
+> management system.
+>
+> Consider sub-sections that describe more specifically:
+>
+> * Customer support availability (typically e.g. 9am - 5pm CET Mon - Fri)
+> * Customer support ticket system (if applicable, consider GDPR requirements for sensitive data)
+> * Contact channels: describe the primary way to contact your customer support (e.g. support email address).
+> * Think about the most commonly used contact channels for your product and organization. Also consider
+>   channels independent from internet connection. Ideally, inquiries should be responded to in the same way of
+>   communication as they were received by.
+> * Feedback prioritization (*optional*, e.g. high - medium - low)
+
+### Feedback Classification
+
+All feedback is classified into one of the following categories. If the Operations team is not sure how to
+classify a ticket, it consults the QMO.
+
+| Feedback Category                                              | Feedback Description                                                                                                                                                                                                                                                                                                                                                                                               |
+|----------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Support Inquiry                                                | Any request for help that can be resolved by providing the user with (usability) information.                                                                                                                                                                                                                                                                                                                      |
+| Change Request                                                 | Any request to add, modify or remove product functionalities.                                                                                                                                                                                                                                                                                                                                                      |
+| Customer Complaint                                             | Any complaint that can be related to our products or organization and which is not classified as an "issue with potential negative influence on patient health".                                                                                                                                                                                                                                                   |
+| Issue with potential negative influence on the state of health | Any customer complaint related to:<br>problem with the medical device that could cause or may have caused or did in fact cause a death or serious deterioration in the state of health.<br>problem with the medical device that significantly impaired the performance criteria of the device (based e.g. on the information given in the intended use, user manual or marketing material). |
+
+> Add more categories as required by your organization. For example: positive feedback (praise), data privacy inquiries, differentiate product complaints <> customer complaints (not product related), etc.
+
+| Serious Deterioration of the State of Health                                                                                                                                                                                                                                                                                                                                                                                      |
+|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| A serious deterioration of the state of health includes at least one of the following:<br>life-threatening illness,<br>permanent impairment of a body function or permanent damage to a body structure,<br>a condition which requires medical or surgical intervention to prevent one of the above,<br>any indirect harm as a consequence of an incorrect diagnostic result when used within manufacturer's instructions for use. |
+
+## Process Steps
+
+### 1. Documentation of Feedback
+
+The Operations team receives feedback through a contact channel, which automatically opens a respective ticket
+in our system (see general considerations above). Based on the input, the Operations team then documents at
+minimum the following information in the ticket:
+
+* Date of feedback
+* Description of the issue (e.g. software version, runtime environment, if available: screenshots / images)
+* Affected users, contact details and customer locations
+* Steps to reproduce the problem
+
+| Participants    |
+|-----------------|
+| Operations team |
+
+| Input                         | Output                                                |
+|-------------------------------|-------------------------------------------------------|
+| Received feedback / complaint | Structured documentation of feedback in ticket system |
+
+
+### 2. Evaluation of Feedback
+
+The Operations team classifies the feedback according to the categories outlined in the general considerations
+of this process.  Depending on the feedback category it takes respective actions:
+
+**Support Inquiry:**
+
+The Operations team actively supports the customer / user in solving the issue by answering questions or
+providing additional user training.
+
+**Change Request:**
+
+The feedback ticket is forwarded to the Product team to decide over implementation and potentially initiate the change management process.
+
+**Customer Complaint:**
+
+* If the customer complaint constitutes a persistent problem related to a medical device that cannot be
+  resolved by providing user information or training (e.g. software bugs), it is forwarded to the Product team
+  to initiate the problem resolution process.
+* If the customer complaint is related to an organizational issue (e.g. sales and marketing efforts), the
+  Operations team involves other teams of the organization where necessary to provide the customer / user with
+  a satisfactory response.
+* If the customer complaint may constitute a systematic issue, the feedback is additionally forwarded to the
+  Quality Management Officer (QMO) to initiate the process for corrective and preventive actions (CAPA).
+
+**Issue with a Potential Negative Impact on the State of Health:**
+
+All issues with a potential negative impact on the state of health must be reported immediately, but no later
+than on the same day, to the Medical Device Safety Officer / Person Responsible for Regulatory Compliance.
+
+All product-related feedback shall be checked for a potential impact on the risk management file or product requirements of the respective device and shall be taken into consideration for device post-market surveillance.
+
+| Participants    |
+|-----------------|
+| Operations team |
+
+| Input               | Output                                      |
+|---------------------|---------------------------------------------|
+| Documented feedback | Classified feedback and decision on actions |
+
+### 3. Validation of Actions
+
+The Operations team proactively receives updates regarding the status of actions per ticket from other teams.
+
+Once the actions are considered completed (e.g. for change requests: decision to implement a feature or not is
+made), the Operations team informs the customer / user and validates if the actions taken are satisfying. If
+so, the validation is documented in the ticket and the ticket is closed. If not, this process is re-initiated.
+
+If a customer / user does not respond, validation is tried at least a second time before the ticket is closed.
+
+| Participants    |
+|-----------------|
+| Operations team |
+
+| Input               | Output                                  |
+|---------------------|-----------------------------------------|
+| Implemented actions | Validation of actions, ticket is closed |
+
+> Optionally, depending on the features that your ticket system provides, consider adding a process step to
+> assign each ticket a status (open, pending input, closed).
diff --git a/openregulatory/templates/qms/sop-internal-audit.md b/openregulatory/templates/qms/sop-internal-audit.md
new file mode 100644
index 00000000..d95a70c9
--- /dev/null
+++ b/openregulatory/templates/qms/sop-internal-audit.md
@@ -0,0 +1,96 @@
+| Regulatory Requirement       | Document Section |
+|------------------------------|------------------|
+| ISO 13485:2016 Section 8.2.4 | All              |
+
+## Summary
+
+This SOP describes how internal auditing is performed for the purpose of reviewing compliance with regulatory
+requirements. It can be used for both internal and supplier audits.
+
+## 1. General Considerations
+
+### 1.1 Auditor Qualification
+
+Auditors that conduct audits must be sufficiently qualified by having attended external auditor training and
+by having participated in audits before.
+
+### 1.2 Audit Guidelines
+
+Auditors must adhere to the following guiding principles:
+
+* **Integrity:** all participants of an audit shall give honest presentations of their views and knowledge,
+  observe confidentiality regarding sensitive information towards third parties and conduct audit work in a
+  thorough manner.
+* **Objectivity**: auditors must act impartial, free of any favoritism and conflicts of interest regarding the
+  subject of their work.
+* **Verifiability:** auditors must collect evidence to support their assessments. Documentation must include
+  audit plans, audit criteria and detailed evidence of audit findings so that outcomes are reliable and
+  comprehensible for later reference.
+
+### 1.3 Audit Findings
+
+The following categories of audit findings are defined for the organization:
+
+**Major Nonconformities (MNC+):**
+
+Major nonconformities are systematic deviations from regulatory requirements that indicate disabilities of the
+organization’s QMS to deliver intended outputs. For instance, major nonconformities would entail the lack of a
+process, repeated minor nonconformity regarding the same process or QMS segment and failure to eliminate the
+cause of that nonconformity.
+
+**Minor Nonconformities (MNC-):**
+
+Minor nonconformities do not indicate systematic malfunctioning of an entire process or the entire QMS. The
+general ability to ensure controlled, conforming processes and products is upheld nevertheless. Examples are
+single, isolated events like a mislabeled document or a missing review documentation.
+
+**Recommendations (REC):**
+
+Recommendations entail auditor advice for improved QMS effectiveness or efficacy.
+
+## 2. Process Steps
+
+### 2.1 Compilation or Revision of Audit Program
+
+Audits are based on the organization’s QMS processes. The QMO is responsible to maintain a perennial audit
+program that ensures:
+
+1. That core processes (as defined in the quality manual) are audited at least annually,
+2. That processes presenting higher compliance risks based on previous audit findings, CAPAs or changes to the
+   QMS system are audited more frequently.
+
+|              |                                       |
+|--------------|---------------------------------------|
+| Participants | QMO                                   |
+| Input        | Previous findings, CAPAs, QMS changes |
+| Output       | (Updated) audit program               |
+
+### 2.2 Conducting Audits
+
+Audits are planned separately by respective auditors, coordination is supported by the QMO. Once a scheduled
+audit date approaches, the QMO informs relevant members of the organization to ensure their availability for
+potential auditor questions during the audit. QMO and auditor together compile an audit plan that specifies
+the audit scope, objectives and participants.
+
+Audit objectives may entail: review of compliance of processes with regulatory requirements, review of
+compliance with processes, review of the effective implementation of corrective and preventive action (CAPA).
+
+Audits are conducted by inspecting appropriate process records and by interviewing members of the
+organization. The auditor documents collected evidence, observations and findings as part of an audit report.
+
+|              |                                                              |
+|--------------|--------------------------------------------------------------|
+| Participants | Auditor, QMO                                                 |
+| Input        | Audit program Quality Management System, incl. records       |
+| Output       | Audit plan (before the audit) Audit report (after the audit) |
+
+### 2.3 Audit Follow-Up
+
+For all major nonconformities resulting from audit findings, a separate CAPA is initiated.
+The QMO reports audit findings to the Management as part of the next Management Review.
+
+|              |                    |
+|--------------|--------------------|
+| Participants | QMO                |
+| Input        | Audit report       |
+| Output       | CAPA documentation |
diff --git a/openregulatory/templates/qms/sop-product-certification-and-registration.md b/openregulatory/templates/qms/sop-product-certification-and-registration.md
new file mode 100644
index 00000000..5b6a1146
--- /dev/null
+++ b/openregulatory/templates/qms/sop-product-certification-and-registration.md
@@ -0,0 +1,129 @@
+| Regulatory Requirement                                                                                                                    | Document Section |
+|-------------------------------------------------------------------------------------------------------------------------------------------|------------------|
+| MDR Annex I (General Safety and Performance Requirements) and Annex IV (EU Declaration of Conformity)                                     | All              |
+| MPDG §8, §96, §97                                                                                                                         | All              |
+| ISO 13485:2015, Sections 4.2.3                                                                                                            | All              |
+
+## Summary
+
+This SOP describes how a medical device is brought to the market while observing applicable regulatory
+requirements, including the compilation of a Technical Documentation and issuing a EU Declaration of
+Conformity for the medical device.
+
+## Process Steps
+
+### 1. Decision on New or Revised Medical Device
+
+This process is initiated once the Management decides to place a new or updated medical device on the
+market. Business input could be:
+
+* Conversations with prospective customers
+* Market opportunities
+* Internal ideas
+
+If applicable, a responsible Product Manager for a new device is appointed. Together with the QMO, they
+determine the classification of a new device as part of the MDR Classification document.
+
+|              |                                         |
+|--------------|-----------------------------------------|
+| Participants | Management, Product Manager, QMO        |
+| Input        | Management decision on new device       |
+| Output       | Completed medical device classification |
+
+### 2. Application for Conformity Assessment by Notified Body
+
+If necessary based on the medical device classification, a Notified Body is involved for the conformity
+assessment for the new device.
+
+> NOTE: a Notified Body must be involved in the conformity assessment of all medical devices except for class I.
+
+|              |                               |
+|--------------|-------------------------------|
+| Participants | Product Manager               |
+| Input        | Medical device classification |
+| Output       | Contract with Notified Body   |
+
+### 3. Compilation of Technical Documentation and Declaration of Conformity
+
+The technical documentation for the medical device is compiled by following respective processes for
+development (e.g. software development, risk management, usability testing). The Product Manager is
+responsible to coordinate this process step with all relevant members of the organization. Documentation for
+different versions of the device is kept separate.
+
+The Product Manager maintains a Medical Devices List according to MDR Annex II Sec 1.2 that provides an overview of:
+* Installed product versions per customer site (if applicable)
+* Previous device versions, incl. release and decommissioning date
+* Similar devices
+
+Prior to submission to the Notified Body for conformity assessment (if applicable), the QMO checks the
+documentation for completeness according to the stipulations listed below. Compliance with EU legislation is documented in the MDR General Safety and Performance Requirements Checklist.
+
+* MDR General Safety and Performance Requirements (Annex I)
+* MDR EU Declaration of Conformity (Annex IV)
+
+After successful approval by the Notified Body, the Management signs the declaration of conformity. A product
+(version) is considered released and placed on the market with the release of its declaration of conformity.
+
+|              |                                                                                                                          |
+|--------------|--------------------------------------------------------------------------------------------------------------------------|
+| Participants | Product Manager, QMO                                                                                                     |
+| Input        | Technical documentation                                                                                                  |
+| Output       | Approval by Notified Body<br>Signed EU Declaration of Conformity<br>Updated List of Medical Devices and Product Versions |
+
+### 4. Registration of Medical Device (UDI)
+
+Country-specific requirements for registration are observed before making a new medical device (version) available in
+a market. For the European market, the Product Manager follows the requirements set out in Art. 29 and Annex
+VI MDR by registering the device’s Unique Device Identifier (UDI) in the European Database for Medical Devices
+(Eudamed).
+
+For the implementation of product changes, the Product Manager applies for a new UDI-DI if the changes entail
+one of the following:
+
+* A significant change based on the Change Evaluation List
+* Changed intended use
+* New product features
+* Changes in product interoperability, new interface or connected systems
+* Non-trivial change to the user interface
+* New supported operating system
+* New programming language
+* New algorithm model
+* Non-trivial change to the software or database architecture
+
+The Product Manager assigns a new UDI-PI for modifications such as:
+
+* Bug fixes
+* Security patches
+* User interfaces (limited to usability and excluding security improvements)
+
+The UDI-PI is determined by the manufacturer. Typically, the device version number serves as the UDI-PI (see SOP Software Development).
+
+> NOTE:
+>
+> * The **Basic UDI-DI** (or: BUDI-DI) is assigned by UDI providers and identifies a **group of medical devices
+>   with the same purpose, risk class, comparable design and manufacturing features.**
+> * The **UDI-DI** is assigned by UDI providers **for each medical device product type** and is revised for any
+>   major modifications (substantial updates) to the device.
+> * The **UDI-PI** you can assign yourself as a manufacturer **for every single product** and is revised for
+>   minor modifications (non-substantial updates).
+
+> **Example:**
+>
+> * Basic UDI-DI: Wrist-band health tracking device
+> * UDI-DI: different code based on color and packaging (white/blue/red; single-/double-pack)
+> * UDI-PI: different code based on series/batch/version, expiration date, etc.
+>
+> NOTE: As of early 2021, the European Commission has designated four entities to issue UDI codes: GS1, HIBCC,
+> ICCBBA and IFA. As long as Eudamed is not set up for registration, national registration requirements
+> apply. For Germany, consider §96 and §97 of the MPDG. At OpenReg, we recommend obtaining a UDI already to be
+> prepared for the regulatory transition.
+>
+> NOTE: As part of the registration process, authorities in non-EU countries may require the documentation to
+> be provided in other languages. Consider norms and regulations for the translation of medical device
+> documentation.
+
+|              |                                                  |
+|--------------|--------------------------------------------------|
+| Participants | Product Manager                                  |
+| Input        | Released Declaration of Conformity               |
+| Output       | Updated or new UDI Completed device registration |
diff --git a/openregulatory/templates/qms/sop-update-of-regulations.md b/openregulatory/templates/qms/sop-update-of-regulations.md
new file mode 100644
index 00000000..10cf3a66
--- /dev/null
+++ b/openregulatory/templates/qms/sop-update-of-regulations.md
@@ -0,0 +1,51 @@
+| Regulatory Requirement                  | Document Section |
+|-----------------------------------------|------------------|
+| ISO 13485:2016 Sections 5.6.2 and 7.3.3 | All              |
+
+## Summary
+
+This SOP describes how the organization identifies changes to regulation applicable either to the organization
+as a manufacturer or its products in the market. This process shall ensure that changes are identified early
+enough and required changes are implemented in a timely manner so that regulatory compliance is guaranteed at
+all times.
+
+## Process Steps
+
+### 1. Regulatory Input / Review
+
+The QMO is responsible to gather all available regulatory information that is potentially relevant for the
+organization and its medical device(s) based on respective documentation provided by the Product
+Manager(s). Input may entail statutory laws, regulations and guidance documents. The QMO analyzes the
+applicability of relevant regulations and documents his assessment in a List of Applicable Regulations.
+
+Relevant input channels may include, but are not limited to:
+* Newsletter of ISO / IEC
+* (For Germany) Beuth newsletter
+* FDA newsletter
+* EU website on harmonized norms
+* Consultancy newsletters (Johner, Open Regulatory, …)
+
+
+Every relevant regulation is reviewed at least once per year, every time before a new medical device is placed
+on the market or as specified by the List of Applicable Regulations.
+
+|              |                                                                                           |
+|--------------|-------------------------------------------------------------------------------------------|
+| Participants | QMO                                                                                       |
+| Input        | Medical device specification (technical documentation), Available regulatory requirements |
+| Output       | List of regulatory requirements                                                           |
+
+### 2. Actions Based on Applicable Regulation
+
+If a new or revised applicable regulation is brought to their attention, the QMO updates the List of
+Applicable Regulations. Where necessary, updates to medical devices are implemented according to the change management process. Where updates to the organization’s quality management system processes are necessary, the QMO implements those directly or delegates implementation to the respective process owners.
+
+The QMO communicates new or revised regulation to relevant members of the organization (e.g. process owners or
+product managers). Management is informed of new or revised regulation at least annually as part of the Management Review.
+As part of the relevant section of the Management Review Report, it is evaluated if updates to applicable regulations have been implemented effectively.
+
+|              |                                                                                                  |
+|--------------|--------------------------------------------------------------------------------------------------|
+| Participants | QMO                                                                                              |
+| Input        | New or revised regulation                                                                        |
+| Output       | List of regulatory requirements (updated), Communication to relevant members of the organization |
diff --git a/openregulatory/templates/qms/vigilance/field-safety-notice.md b/openregulatory/templates/qms/vigilance/field-safety-notice.md
new file mode 100644
index 00000000..8ca584a2
--- /dev/null
+++ b/openregulatory/templates/qms/vigilance/field-safety-notice.md
@@ -0,0 +1,69 @@
+### (Enter Company Name)
+
+### Field Safety Notice for (Enter Product Name and Version Number)
+
+(Enter Date)
+
+> Keep in mind that FSN has to be written in the language of the country you are operating your device in, so
+> you may have to translate this template text.
+>
+> For your orientation: the German BfArM has also published [past reports as templates][bfarm-past-reports] to
+> be used by other manufacturers.
+
+#### (Page 1: Cover Letter)
+
+Dear Customer,
+
+Our company's products are subject to continuous and rigorous surveillance to ensure ongoing safety and
+reliability while being used.
+
+As part of our product surveillance, we identified a potential problem that could impact the performance of
+the device.
+
+We would therefore like to provide you with the following information:
+
+* description of the problem and under which circumstances it may occur
+* recommended actions to avoid the problem or minimize its implications
+* actions planned by (company name) to resolve the problem
+
+If you need any further information or support concerning this, please reach out to our company
+representative: (Company Contact Details and Responsible Person)
+
+We would like to apologize for any inconvenience.
+
+Sincerely,
+
+(Enter name of responsible Medical Device Safety Officer / Person Responsible for Regulatory Compliance)
+
+---
+
+#### (Page 2: FSN Report)
+
+**(Product Name)**
+
+**Field Safety Notice for (Version Number)**
+
+(Date)
+
+**This document contains important information for the continued safe and proper use of your medical device.**
+
+*Please review the following information with all members of your staff who need to be aware of the contents
+of this communication. It is important to understand the implications of this communication. Please retain a
+copy with the Instructions for Use and confirm the receipt of this notice.*
+
+|                                    |                                                                     |
+|------------------------------------|---------------------------------------------------------------------|
+| Affected Product:                  |                                                                     |
+| Unique Device Identification:      |                                                                     |
+| Version:                           |                                                                     |
+| Problem Description:               |                                                                     |
+| Hazard Involved:                   |                                                                     |
+| Recommended Actions:               |                                                                     |
+| Actions Planned by (company name): |                                                                     |
+| Further Information and Support:   | (Refer to a country contact including information on availability.) |
+
+
+
+<!-- Links -->
+
+[bfarm-past-reports]: https://www.bfarm.de/SharedDocs/Kundeninfos/DE/17/2018/00193-18_kundeninfo_de.pdf?__blob=publicationFile&v=1
diff --git a/openregulatory/templates/qms/vigilance/incident-assessment-form.md b/openregulatory/templates/qms/vigilance/incident-assessment-form.md
new file mode 100644
index 00000000..7c97f428
--- /dev/null
+++ b/openregulatory/templates/qms/vigilance/incident-assessment-form.md
@@ -0,0 +1,99 @@
+# Incident Assessment Form
+
+| Regulations                                  | Document Section |
+|----------------------------------------------|------------------|
+| Medical Device Regulation Art. 87 and 89     | All              |
+| Medical Device Directive Art. 10             | All              |
+| ISO 13485:2016 Section 8.2.3                 | All              |
+| MPDG, MPEUAnpV, MEDDEV 2.12/1 rev. 8         | All              |
+
+## Summary
+
+This template is used to assess whether an event with a potentially negative impact on the state of health
+constitutes a serious and reportable incident.
+
+| General Information      |                                                                                                                             |
+|--------------------------|-----------------------------------------------------------------------------------------------------------------------------|
+| Description of Event:    | *\<Describe e.g. the cause that led to the event, the relationship between device and event, urgency of required actions\>* |
+| Report Date and Time:    |                                                                                                                             |
+| Affected Medical Device: | *\<Enter UDI here\>*                                                                                                        |
+| Incident Assessment:     | The event is a reportable incident:<br>( ) Yes ( ) No                                                                       |
+| Action Planned:          | *\<Describe FSCA\>*                                                                                                         |
+
+## Incident Assessment Framework
+
+The following criteria are based on the MEDDEV 2.12/1 rev. 8 guidance document. Any event which meets **all
+three criteria listed below** is considered a serious incident and must be reported to the competent national
+authorities.
+
+> For correct understanding, keep in mind that the template form below can be also used to document
+> appropriately why an event was NOT considered a reportable incident!
+
+### (1) General Event Description and Occurrence
+
+**Criterion:** An event has occurred that could be considered a serious and reportable incident.
+
+|                   |                                                  |
+|-------------------|--------------------------------------------------|
+| Applicable?       | ( ) Yes ( ) No                                   |
+| Explanation:      | *\<if no, describe why this is not applicable\>* |
+| Category of event |                                                  |
+
+> Examples of possible event categories are as follows. For more examples, see MEDDEV 2.12/1 rev. 8 guidance.
+>
+> * Technical failure mode leading to unexpected behavior of a medical device
+> * Incorrect product claims (marketing material, instructions for use, labeling)
+> * New hazard-related use scenario occurred, i.e. usability problem
+
+*Note: The incident assessment must also consider information resulting from testing, reading the instructions
+for use or scientific data that indicate implications as outlined in step 3 below.*
+
+### (2) Relationship Between the Device and Event
+
+**Criterion:** A (direct or indirect) causal relationship is suspected between the device and the event.
+
+|              |                                                |
+|--------------|------------------------------------------------|
+| Applicable?  | ( ) Yes ( ) No                                 |
+| Explanation: | \<if no, describe why this is not applicable\> |
+
+*Note:* *When assessing the relationship between the device and event the Person Responsible for Regulatory Compliance must take the following points into consideration:*
+
+* *The opinion of subject matter experts (e.g. physicians)*
+* *The PRRC assessment;*
+* *Previous / similar events and incidents*
+
+*From a risk management perspective, this decision should be made conservatively, i.e. if the situation is
+complex and/or potentially caused by multiple medical devices, the PRRC should have a tendency to
+assess this as "applicable" even if the matter still remains unclear.*
+
+### (3) Event Outcomes
+
+**Criterion:** The event led, or might have led, to one of the following outcomes:
+
+|              |                                                                                                                                 |
+|--------------|---------------------------------------------------------------------------------------------------------------------------------|
+| Applicable?  | ( ) Yes ( ) No                                                                                                                  |
+| Explanation: | \<if no, describe why this is not applicable\>                                                                                  |
+| Outcome:     | ( ) death of a patient, user or other person<br>( ) serious deterioration in state of health of a patient, user or other person<br>( ) serious public health threat |
+
+*A serious deterioration in state of health results in at least one of the following:*
+
+* *life-threatening illness or injury*
+* *permanent impairment of a body structure or a body function*
+* *hospitalization or prolongation of patient hospitalization or a condition which requires medical or surgical intervention to prevent any of the above*
+* *chronic disease*
+* *any indirect harm as a consequence of an incorrect diagnostic result when used within manufacturer’s instructions for use*
+
+> Please note: Serious incidents may also include events where serious medical consequences have not occurred yet but could
+> occur in the future under similar circumstances. If you are unsure, check the intended use of the device to
+> assess whether the event should be excluded based on its (counter-)indications.
+
+## Guidance for Assessment
+
+| Guidance Document | Explanation |
+|-------------------|-------------|
+| **Intended Purpose**<br>*See MEDDEV 2.12/1, section 4.6 'Definitions'; See MDD Article 1.2 paragraph (g)* | The use for which the device is intended according to the data supplied by the manufacturer on the labeling, in the instructions for use and/or in promotional materials. |
+| **Incident**<br>*See MEDDEV 2.12/1, section 4.6 'Definitions' and annex I for examples* | Any malfunction or deterioration in the characteristics and/or performance of a device, as well as any inadequacy in the labeling or the instructions for use which, directly or indirectly, might lead to or might have led to the death of a patient, or user or of other persons or to a serious deterioration in their state of health. |
+| **Direct or Indirect Harm**<br>*See MEDDEV 2.12/1, section 4.6 'Definitions'* | A physical injury or damage to the health of people, or damage to property or the environment.In the majority of cases, diagnostic devices will, due to their intended use, not directly lead to physical injury or damage to health of people. These devices are more likely to lead to indirect harm. Harm may then occur as a consequence of the medical decision, action taken/not taken on the basis of information or result(s) provided by the device or as a consequence of the treatment of cells or organs outside of the human body that will later be transferred to a patient.<br>Examples of indirect harm include misdiagnosis, delayed diagnosis, delayed treatment, inappropriate treatment, absence of treatment transfusion of inappropriate materials. Indirect harm may be caused by imprecise results, inadequate quality controls, inadequate calibration, false positive or false negative results. |
+| **Field Safety Corrective Actions**<br>*See MEDDEV 2.12/1, section 4.6 'Definitions'* | FSCA is an action taken by a manufacturer to reduce a risk of death or serious deterioration in the state of health associated with the use of a medical device that is already placed on the market. Such actions, whether associated with direct or indirect harm, should be reported and should be notified via a field safety notice.<br><br>FSCA may include: the return of a device to the supplier; device modification; device exchange; device destruction; advice given by manufacturer regarding the use of the device and/or the follow-up of patients, users or others (e.g. where the device is no longer on the market or has been withdrawn but could still possibly be in use).<br><br>Manufacturers can as part of ongoing quality assurance identify a failure of a device to perform according to the characteristics specified in the information for use provided by the manufacturer. If the failure might lead to or might have led to death or serious deterioration in the state of health associated with the use of a medical device and has an impact on a product that has already been placed on the market the manufacturer must initiate a FSCA.<br><br>Examples of failure modes may include software anomalies (e.g. incorrect correlation between patient sample and the obtained result, invalid controls or invalid calibrations).<br><br>A device modification can include:<br>\- Permanent or temporary changes to the labeling or instructions for use \(for example: advice for revised quality control procedures such as use of third party controls\, more frequent calibration or modification of control values\)\.<br>\- Software upgrades following the identification of a fault in the software version already in the market\. This should be reported regardless of whether the software update is being implemented by customers\, field service engineers or by remote access\.<br><br>Advice given by the manufacturer may include modifications to the clinical management of patients or samples to address a risk of death or a serious deterioration in state of health related to the characteristics of the device. For diagnostic devices, corrective action taking the form of the recall of patients or patient samples for retesting or the review of previous results constitutes FSCA. |
diff --git a/openregulatory/templates/qms/vigilance/sop-vigilance.md b/openregulatory/templates/qms/vigilance/sop-vigilance.md
new file mode 100644
index 00000000..46977488
--- /dev/null
+++ b/openregulatory/templates/qms/vigilance/sop-vigilance.md
@@ -0,0 +1,237 @@
+# SOP Vigilance
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 8.2.3                  | All              |
+
+| Medical Device Regulation | Document Section |
+|---------------------------|------------------|
+| Art. 87                   | All              |
+
+> Regulatory references: check MEDDEV 2.12./1 for guidance on this topic. As a German manufacturer, you are
+> also subject to national law which lays out more specific requirements (note that in preparation for MDR,
+> the Medizinproduktegesetz (MPG) was replaced by the Medizinprodukte-Durchführungsgesetz (MPDG) and the
+> Medizinprodukte-EU-Anpassungsverordnung (MPEUAnpV) replaced the old
+> Medizinprodukte-Sicherheitsplanverordnung (MPSV)).
+
+## Summary
+
+This SOP describes how we handle (potentially) serious incidents and field safety corrective action (FSCA). It outlines how we follow the
+requirements for reporting to competent authorities and necessary immediate action.
+
+## General Considerations
+
+### Reportable Serious Incident
+An incident is defined as any malfunction or deterioration in the characteristics or performance of a device made available on the market, including use-error due to ergonomic features, as well as any inadequacy in the information supplied and any undesirable side-effect.
+
+Any incident that our organization becomes aware of is reportable, if one of our medical devices could be its
+cause and if it fulfills the definition of a serious incident as outlined in this process. Potentially serious incidents are
+assessed based on our respective template form for incident assessment [reference document ID here].
+
+A serious incident is defined as “*any malfunction or deterioration in the characteristics and/or performance of a device, as well as any inadequacy in the labeling or the instructions for use which, directly or indirectly, might lead to or might have led to the death of a patient, user or other person or to a serious deterioration in their state of health or a serious public health threat*” (see MDR Art. 2 and MEDDEV 2.12./1). Examples are therefore (non-exclusively):
+* malfunctioning (e.g. a software bug) of one of our medical devices
+* incorrect labeling, instruction for use or advertising material
+* usability deficiency causing a misuse
+
+A serious deterioration in state of health results in at least one of the following:
+* life-threatening illness or injury
+* permanent impairment of a body structure or a body function
+* hospitalization or prolongation of patient hospitalization or a condition which requires medical or surgical intervention to prevent any of the above
+* chronic disease
+* any indirect harm as a consequence of an incorrect diagnostic result when used within manufacturer’s instructions for use
+
+> Note that: not all incidents lead to death or serious deterioration in health. The non-occurrence of such a
+> result might have been due to fortunate circumstances or to the intervention of healthcare personnel. It is
+> sufficient that: (a) an incident associated with a device happened, and (b) the incident was such that, if
+> it occurred again, it might lead to death or serious deterioration in health.
+
+### Field Safety Corrective Action (FSCA)
+
+A field safety corrective action (FSCA) is an action taken to reduce a risk of death or serious deterioration
+in the state of health associated with a device that is already placed on the market. Such actions, whether
+related to direct or indirect harm, should be reported and informed about via a field safety notice. FSCAs can
+include (non-exclusively):
+
+* the return of a medical device to the manufacturer (recall)
+* modification of a medical device, which can include: design changes (e.g. software update), permanent or
+  temporary changes to the labeling or the instructions for use, changes to make device temporarily not
+  available to users (software lock)
+* advice provided by the manufacturer regarding the use or operation of the device
+
+### Reporting Timescale
+
+* In the event of imminent danger:
+    * **Immediately** (without any delay that could not be justified)
+* In the event of a serious public health threat:
+    * **Immediately** after a link was established between the device and the event, **but no later than 2 elapsed calendar days** following the date of awareness of the event.
+* Death or serious deterioration in state of health:
+    * **immediately** after a link was established between the device and the event, **but no later than 10 elapsed calendar days** following the date of awareness of the event.
+* Other reportable incidents:
+    * **Immediately** after a link was established between the device and the event, **but not later than 15 elapsed calendar days** following the date of awareness of the event.
+* Field Safety Corrective Action (FSCA):
+    * **Immediately**, at latest with the beginning of the implementation of actions.
+
+All report times refer to when the national responsible authority must first be notified. In case of uncertainty whether the incident has to be reported or not, it is reported within the above deadlines.
+
+### Responsible Authorities
+
+Incidents are reported to the authority of the country in which the reportable incident occurred:
+
+**Germany:**
+
+* Federal Institute for Drugs and Medical Devices (BfArM)
+* Website: www.bfarm.de 
+* Email: medizinprodukte@bfarm.de; Phone: +49 228 207 5355
+* Incident reporting: look for “MIR Formular”
+
+
+**Spain:**
+
+* Spanish Agency for Drugs and Medical Products (AEMPS)
+* Website: www.aemps.gob.es
+* Email: sgps@aemps.es
+* Phone: +34918225274
+
+
+**Netherlands:**
+
+* CIBG-Farmatec
+* Website: www.igj.nl
+* Email: medische_hulpmiddelen@minvws.nl
+
+
+**Poland:**
+
+* Office for the Registration of Medical Products (URPLWMiPB)
+* Website: www.urpl.gov.pl/en
+* Email: incydenty@urpl.gov.pl
+* Phone:+48 22 492 11 90
+
+
+**Other national authorities:**
+
+More contact data can be found on the website of the European Commission:
+https://ec.europa.eu/health/medical-devices-sector/new-regulations/contacts_en 
+
+FSCA is reported to the authorities in the countries in which the FSCA is carried out, including incidents
+which occurred outside of the European Economic Area (EEA) but resulted in a recall within European countries.
+
+In parallel to reporting incidents to responsible authorities, our Notified Body is informed where applicable
+in respect to the applied conformity assessment procedure.
+
+## Process Steps
+
+### 1. Documentation and Immediate Action
+
+Any employee of the company that obtains knowledge of an event with a potentially negative impact on the state of health shall immediately notify the Person Responsible for Regulatory Compliance (PRRC) to initiate this process.
+
+However, input to this process may arrive through multiple input channels (see below). Input channels must be checked regularly, for example, throw continuous post-market surveillance cycles (see process for post-market surveillance).
+
+* Own employees
+* Device users (e.g. feedback, see process for feedback management)
+* Authorities (e.g. who were informed of a serious incident)
+* Post-market surveillance (e.g. events with similar devices trigger own FSCA, see process for post-market surveillance)
+
+In a first step, the PRRC opens a CAPA to document the respective event.
+Where necessary, immediate action is initiated without undue delay as part of the CAPA process.
+
+| Participants                                              |
+|-----------------------------------------------------------|
+| Person Responsible for Regulatory Compliance (PRRC)|
+
+| Input                                                           | Output                                                             |
+|-----------------------------------------------------------------|--------------------------------------------------------------------|
+| Event with a potentially negative impact on the state of health | Documented incident and initiated immediate action where necessary |
+
+### 2. Investigation of Causal Relationship
+
+Secondly, the PRRC investigates the root causes of the event to determine if there is a causal relationship between the use of the medical device and the event. The investigation is documented as part of the CAPA process.
+
+If there is no causal relationship, the event is not considered a reportable serious incident. In such cases, the PRRC proceeds with para. 5 to assess if FSCA is required nevertheless (for example, to prevent the occurrence of reportable events).
+
+| Participants |
+| ------------ |
+| Person Responsible for Regulatory Compliance (PRRC) |
+
+| Input | Output |
+| ----- | ------ |
+| Documented incident | Documented evaluation of causal relationship |
+
+### 3\. Evaluation as Reportable Incident
+
+If there is a relationship, the PRRC evaluates if the event qualifies as a reportable serious incident by filling out the incident assessment form. Only serious incidents and FSCA must be reported (Art. 87 MDR). In the case of uncertainty, the event is always reported as a serious incident.
+
+Where it is determined that the incident is not a serious incident or is an expected undesirable side-effect, which will be covered by trend reporting in accordance with the process for post-market surveillance, an explanatory statement must be documented in the incident assessment form.
+
+| Participants |
+| ------------ |
+| Person Responsible for Regulatory Compliance (PRRC) |
+
+| Input | Output |
+| ----- | ------ |
+| Documented incident and causal relationship | Documented evaluation as a reportable incident |
+
+
+### 4. Reporting of Incidents and Field Safety Corrective Action (FSCA)
+
+Within the applicable reporting timescale (see general considerations above), the PRRC informs the
+competent national authority about the event using respective reporting forms. The PRRC compiles and provides a
+report with all information required and available at the time.
+
+If applicable, a copy of the report is sent to the Notified Body involved in the conformity assessment procedure of the device.
+
+| Participants                                               |
+|------------------------------------------------------------|
+| Person Responsible for Regulatory Compliance (PRRC) |
+
+| Input                                | Output                                                 |
+|--------------------------------------|--------------------------------------------------------|
+| Completed evaluation of the incident | Completed reporting to authorities (and Notified Body) |
+
+### 5. Initiate Field Safety Corrective Action (FSCA)
+
+Based on a risk and root cause analysis of the event, the PRRC decides if field safety corrective actions (FSCA) are required to reduce existing risks (note: FSCA may also be required to prevent the occurrence of reportable events). Possible FSCAs are described as part of the general considerations of this process.
+
+Before actions are taken, we identify affected users / customers and inform them about such actions as part of a field safety notice (FSN). The FSN is written in the language of the respective country and must at minimum include:
+
+* Subject: **Safety Alert**
+* Manufacturer information (e.g. contact details)
+* Information to identify the affected devices (e.g. device name and software version)
+* Description of the incident including resulting risks and the reasons for FSCA
+* If applicable, actions recommended to the user / customer. For example, this could include actions to
+  restore the safety or recommended clinical investigations.
+
+A copy of the FSN shall be archived. Customers confirm the receipt of FSNs as well as the implementation of recommended actions. If a customer does not respond, at least three attempts for delivery should be made. It is also documented as part of the CAPA if all attempts to inform a customer were unsuccessful.
+
+For B2B customers of our devices, respective contact details for vigilance purposes must be documented as part of CERT-LIS-DEV. For B2C customers, contact details which allow unique identification of end users must be stored separately for every device.
+
+All FSCA are documented as part of the CAPA and must be reported to competent national authorities as described in the previous para. 4.
+
+> You may want to consider a separate process regarding the handling of non-conforming products. This process
+> would entail labeling instructions for respective product code and instructions for employees handling those
+> products.
+
+
+| Participants                                               |
+|------------------------------------------------------------|
+| Person Responsible for Regulatory Compliance (PRRC) |
+
+| Input                         | Output                                             |
+|-------------------------------|----------------------------------------------------|
+| Risks resulting from incident | Implemented FSCA, Reporting of FSCA to authorities |
+
+### 5. Verification and Evaluation of Effectiveness
+
+The effectiveness of implemented FSCAs is evaluated as part of the CAPA. As soon as the CAPA is closed, a final
+report is sent to the responsible authorities to verify that all actions taken are deemed sufficient for
+completion.
+
+All incident records shall be archived as part of the QMS.
+
+| Participants                                               |
+|------------------------------------------------------------|
+| Person Responsible for Regulatory Compliance (PRRC) |
+
+| Input                  | Output                                |
+|------------------------|---------------------------------------|
+| Implementation of FSCA | Final incident report and closed CAPA |
diff --git a/openregulatory/templates/techdoc/14971/risk-management-plan.md b/openregulatory/templates/techdoc/14971/risk-management-plan.md
new file mode 100644
index 00000000..7983ac19
--- /dev/null
+++ b/openregulatory/templates/techdoc/14971/risk-management-plan.md
@@ -0,0 +1,124 @@
+# Risk Management Plan
+
+The Risk Management Plan contains the risk policy and defines the criteria for risk acceptance. It also references relevant processes and activities which will be conducted for product-specific risk management as part of the integrated software development process (SOP Integrated Software Development).
+
+## Mapping of Standard Requirements to Document Sections
+
+| ISO 14971:2019 Section | Document Section                                |
+|------------------------|-------------------------------------------------|
+| 4.1                    | 1                                               |
+| 4.2                    | 1.2, 3                                          |
+| 4.3                    | (Records of competence are kept as Part of QMS) |
+| 4.4                    | (all)                                           |
+| 4.5                    | (all)                                           |
+| 5.1                    | 1.1                                             |
+| 7.2                    | 1.3                                             |
+| 10.1                   | 1.4                                             |
+
+## 1. Relevant Processes
+
+### 1.1 Risk Management Process and Activities
+
+Risk Management Activities are integrated in the software development lifecycle as described in SOP Integrated
+Software Development.
+
+### 1.2 Risk Policy and Risk Acceptability
+
+The following policy establishes criteria for risk acceptability following ISO 14971:2019 and ISO/TR 24971:2020. It applies to all people and activities involved in the design, development and distribution process of the medical device, and intends to ensure highest levels of medical device safety consistent with stakeholder expectations.
+
+The manufacturer defines framework criteria for risk acceptability in the form of estimated usage, severity of harm and probability of occurrence (para. 1.2.1 - 1.2.3). The criteria are initially defined as part of the early software development process and reviewed during every post-market surveillance cycle.
+
+Estimated usage, categories of severity / probability and risk matrix acceptance are defined based on applicable regulatory requirements, relevant international norms and standards, as well as the generally acknowledged state of the art (e.g. accepted results of scientific research, reports published by authorities, established industry best practices).
+
+Acceptability for individual risks always must be established based on both, the estimated severity and the estimated probability of a risk. The risk is deemed acceptable based on a combination of both, following the risk matrix defined in para. 1.2.4.
+
+Acceptability of the overall residual risk is established as part of the clinical evaluation process by weighing benefits from intended use against the overall residual risk. Benefits may be described by their magnitude or extent, the probability of experience within the intended patient population, the duration and frequency of the benefit. For example, the manufacturer may compare the device to similar medical devices available on the market: residual risks can be compared individually to corresponding risks of the similar device, considering differences in intended use. The overall evaluation of the benefit-risk-ratio should take into account knowledge of the intended medical indication, the generally acknowledged state of the art in technology and medicine, and the availability of alternative medical devices or treatments.
+
+#### 1.2.1 Estimates for Usage
+
+> Define estimates for how much you think your device is going to be used in the market.
+
+| Usage               | Values                                                                                                             |
+|---------------------|--------------------------------------------------------------------------------------------------------------------|
+| Product life span   | Enter number of years you expect the device to be in the market (from design conceptualization to decommissioning) |
+| Users               | Enter number of estimated users here                                                                               |
+| Usages / user       | Enter number of estimated times the device is used per user                                                        |
+| Total usages        | Do the math!                                                                                                       |
+
+#### 1.2.2 Severity of Harm
+
+> Define what can go wrong with your product here. Make the examples specific - chances are, your product
+> can't cause skin lacerations. In all likelihood it also doesn't cause death. So, feel free to remove
+> severity rows here. But most importantly, customize the definitions and examples so that they resemble the
+> harms in your product.
+
+| Severity         | Definition and Examples                                                                                   |
+|------------------|-----------------------------------------------------------------------------------------------------------|
+| S1: Negligible   | Minor, reversible damage, e.g. superficial skin irritation, delay of non-critical treatment               |
+| S2: Marginal     | Minor, reversible damage with required medical intervention, e.g. skin laceration requiring stitches      |
+| S3: Critical     | Major, irreversible damage with required medical intervention, e.g. irreversible deterioration of disease |
+| S4: Catastrophic | Death                                                                                                     |
+
+#### 1.2.3 Probability of Occurrence
+
+> Define your probabilities. You can probably just use these definitions. The idea is that each probability
+> row is 10^2 apart from adjacent ones.
+
+> Also, change the "Estimated Maximum Event Count". That's the usage number you estimate for your (not yet
+> released product) during its entire lifecycle (which you need to define). So, if you assume that your
+> product will be on the market for 4 years and that it'll be used 100 times per day, that results in 146.100
+> usages (100 usages/day * 365.25 days/year * 4 years). The numbers in the lower columns of "Estimated Maximum
+> Event Count" are simply the total usage number multiplied by the upper limit probability of the same row,
+> e.g. you want to know "how often can probability P3 occur if the product is being used 100 times per day?"
+
+| Probability  | Upper Limit | Lower Limit | Estimated Maximum Event Count |
+|--------------|-------------|-------------|-------------------------------|
+| P5: Certain  | 1           | 10^-2       | 1000000 *(change this*)       |
+| P4: Likely   | 10^-2       | 10^-4       | 10000                         |
+| P3: Possible | 10^-4       | 10^-6       | 100                           |
+| P2: Unlikely | 10^-6       | 10^-8       | 1                             |
+| P1: Rare     | 10^-8       | 0           | 0                             |
+
+#### 1.2.4 Risk Acceptance Matrix
+
+> The most important part. You assess each severity-probability combination whether it's acceptable for you as
+> a company. There are no definitive rules on what's deemed acceptable. It depends on your company's risk
+> policy and, more importantly, the benefits of your product which you show in your clinical evaluation. So,
+> for example, if your product saves 10 lives per day, it might be acceptable to cause one death per day. If
+> your product doesn't save any lives, it might not be acceptable to cause any deaths. You get the idea, I
+> hope.
+
+| Probability     | S1: Negligible | S2: Marginal     | S3: Critical     | S4: Catastrophic | Estimated Maximum Event Count |
+|-----------------|----------------|------------------|------------------|------------------|-------------------------------|
+| P5: Certain     | acceptable     | **unacceptable** | **unacceptable** | **unacceptable** | 1000000                       |
+| P4: Likely      | acceptable     | **unacceptable** | **unacceptable** | **unacceptable** | 10000                         |
+| P3: Unlikely    | acceptable     | acceptable       | **unacceptable** | **unacceptable** | 100                           |
+| P2: Rare        | acceptable     | acceptable       | acceptable       | **unacceptable** | 1                             |
+| P1: Unthinkable | acceptable     | acceptable       | acceptable       | acceptable       | 0                             |
+
+### 1.3 Verification of Risk Control Measures
+
+Risk Control Measures are verified as described in the software development lifecycle as described in SOP Integrated
+Software Development.
+
+### 1.4 Assessment of the overall residual risk
+
+After determination of the Risk Control Measures any risk that could arise from the combination of the individual risks or mitigating measures is assessed. For this purpose, the probability and severity of the possible residual risk are estimated and evaluated using the existing risk matrix.
+
+### 1.5 Collection and Review of Post-Production Information
+
+Review and collection of Post-Production information is described in SOP Post-Market Surveillance.
+
+## 2. Related Documents
+
+ * SOP Integrated Software Development
+ * Risk Acceptance Matrix
+ * Risk Table
+ * Risk Management Report
+
+## 3. Roles
+
+| Title                                           | Name(s) |
+|-------------------------------------------------|---------|
+| Risk Manager                                    |         |
+| Context / Subject Matter Expert, e.g. physician |         |
diff --git a/openregulatory/templates/techdoc/14971/risk-management-report.md b/openregulatory/templates/techdoc/14971/risk-management-report.md
new file mode 100644
index 00000000..2c519445
--- /dev/null
+++ b/openregulatory/templates/techdoc/14971/risk-management-report.md
@@ -0,0 +1,106 @@
+# Risk Management Report
+
+The Risk Management Report contains the output and summary of risk management activities. The general planning
+and methods are described in the Risk Management plan, while the actual risks are listed and analyzed in the
+Risk Table.
+
+The process and stages of risk analysis are described in the SOP Integrated Software Development.
+
+## Mapping of Standard Requirements to Document Sections
+
+| ISO 14971:2019 Section                | Document Section             |
+|---------------------------------------|------------------------------|
+| 4.5 Risk management file              | (all)                        |
+| 7.4 Benefit-risk analysis             | 6                            |
+| 7.6 Completeness of risk control      | (by review of this document) |
+| 8 Evaluation of overall residual risk | 3, 5                         |
+| 9 Risk management review              | (all)                        |
+
+## 1. Relevant Processes and Documents
+
+ * SOP Integrated Software Development
+ * Risk Management Plan
+ * Risk Acceptance Matrix
+ * Risk Table
+
+## 2. Risk Analysis
+
+> The general idea about this section is that you simply summarize the amount of stuff you added to your Risk
+> Table (a separate document).
+
+### 2.1 Preliminary Hazards Analysis
+
+*\<no. of hazards\>* hazards were identified based on the Intended Use and Usability Tests. They were further
+analyzed in the Risk Table.
+
+### 2.2 Failure Modes
+
+*\<no. of failure modes\>* failure modes of software systems were identified. They were further analyzed in
+the Risk Table.
+
+### 2.3 Failure Mode and Effects Analysis (FMEA)
+
+All preliminary hazards and potential failure modes of the software were analyzed. In total, *\<no. of
+hazards\>* were identified. The hazardous situation(s) and harm(s) which they could lead to were analyzed,
+including intermediate probabilities (p1 and p2).
+
+## 3. Risk Control Measures
+
+Risks were reduced as far as possible (AFAP). If a risk was classified as "unacceptable" based on
+the Risk Table, Risk Control Measures were implemented.
+
+The following categories of Risk Control Measures were implemented in priority as listed below:
+
+1. Inherent safety by design
+2. Protective measures
+3. Information for safety 
+
+In total, *\<no. of risk control measures\>* were implemented.
+
+## 4. Risk Matrix
+
+After implementation and verification of all Risk Control Measures, the count of risks in the Risk Acceptance
+Matrix was as follows:
+
+| Probability  | S1: Negligible | S2: Marginal        | S3: Critical        | S4: Catastrophic    | Estimated Maximum Event Count |
+|--------------|----------------|---------------------|---------------------|---------------------|-------------------------------|
+| P5: Certain  | acceptable: 0  | **unacceptable: 0** | **unacceptable: 0** | **unacceptable: 0** | 1000000                       |
+| P4: Likely   | acceptable: 0  | **unacceptable: 0** | **unacceptable: 0** | **unacceptable: 0** | 10000                         |
+| P3: Possible | acceptable: 0  | acceptable: 0       | **unacceptable: 0** | **unacceptable: 0** | 100                           |
+| P2: Unlikely | acceptable: 0  | acceptable: 0       | acceptable: 0       | **unacceptable: 0** | 1                             |
+| P1: Rare     | acceptable: 0  | acceptable: 0       | acceptable: 0       | acceptable: 0       | 0                             |
+
+## 5. Summary of Risks and Unacceptable Risks
+
+> If you don't have unacceptable risks (more likely), use this section:
+
+After Risk Control Measures, no unacceptable risks remained. The software, therefore, fulfils the specifications
+of the defined risk policy and is safe. A Benefit-Risk Assessment is not required.
+
+> If you still have unacceptable risks, use this section:
+
+After Risk Control Measures, *\<no. of unacceptable risks\>* unacceptable risks remained. They will be further
+assessed in the Benefit-Risk Assessment below.
+
+> Optionally, mention here your device's software safety classification according to IEC 62304, resulting from the worst possible risks found above.
+
+## 6. Benefit-Risk Assessment
+
+> Only use this whole section (Risk-Benefit Assessment) if you have unacceptable risks.
+
+The *\<no. of unacceptable risks\>* remaining unacceptable risks are compared to the benefits resulting from
+the Clinical Evaluation Report.
+
+The benefits are as follows:
+
+*\<Copy-paste benefits from Clinical Evaluation\>*
+
+> Add a conclusion on whether the benefits outweigh the risks
+
+Weighing the benefits against the risks, we conclude that...
+
+## 7. Overall Residual Risk
+
+> Take a look at your risk mitigating measures and assess whether the combination of them could lead to a risk that has not been taken care of yet, e.g., if one mitigation serves two or more risks at once.
+
+The overall residual risk is estimated to have a probability of *\<probability of residual risk\>* and a severity of *\<severity of residual risk\>*. According to the Risk Acceptance Matrix the overall residual risk is assessed as *\<acceptable\>*.
diff --git a/openregulatory/templates/techdoc/14971/risk-table-fmea.md b/openregulatory/templates/techdoc/14971/risk-table-fmea.md
new file mode 100644
index 00000000..75d9b085
--- /dev/null
+++ b/openregulatory/templates/techdoc/14971/risk-table-fmea.md
@@ -0,0 +1,123 @@
+# Failure Mode and Effects Analysis (FMEA): Risk Table
+
+| ISO 14971:2019 Section | Document Section                                   |
+|------------------------|----------------------------------------------------|
+| 5.2                    | (all; entries about reasonably foreseeable misuse) |
+| 5.4                    | 3                                                  |
+| 5.5                    | 3, 4                                               |
+| 6                      | 3                                                  |
+| 7.1                    | 4                                                  |
+| 7.2                    | 4                                                  |
+| 7.3                    | 4                                                  |
+| 7.5                    | 4                                                  |
+
+| IEC 62366-1:2015 Section | Title                                                          | Document Section |
+|--------------------------|----------------------------------------------------------------|------------------|
+| 4.1.2                    | Risk Control as it relates to User Interface design            | 4                |
+| 5.3                      | Identify known or foreseeable Hazards and Hazardous Situations | 1,3              |
+
+This is a Failure Mode and Effects Analysis ([FMEA][wikipedia-fmea]) of the device. It is separated into
+multiple sections:
+
+ * **Failure Modes** lists everything which can go wrong
+ * **Hazards and Analysis** lists everything (harms) which can subsequently happen, including an analysis of
+   probability and severity
+ * The list of **Risk Control Measures** contains all control measures which were implemented for risk
+   reduction, either reducing probability or severity, or both.
+
+> Ugh, this became more complex than I initially expected. I am so sorry. From a teaching perspective, it's
+> actually simpler to explain if I throw everything into one table. Instead, we have three here now, because I
+> can't trivially upload spreadsheets to the website, so I had to reduce the column count to make them
+> fit. Painful. I'll try to explain as we go along.
+
+## 1. Preliminary Hazards Analysis (PHA)
+
+> A Preliminary Hazards Analysis (PHA) is simply a list of stuff which can go wrong. Typically, you come up
+> with that stuff when you think about your product. Like, when you do Covid predictions, you come up with the
+> thought that a wrong prediction will result in a bad outcome. Makes sense. So, here's a table in which you
+> can collect those ideas. Besides the description it also has the column "source" which describes where the
+> idea came from (typical options are: Intended Use, User Test, 14971 checklist (there is one in the 2012
+> version, otherwise there's TR 24971, I think)) and "Hazard ID(s)" which shows where you've continued the
+> analysis (including probability and severity) of that risk. It refers to the ID(s) in the Hazards and
+> Analysis table below.
+
+| ID | Source                 | Description                           | Hazard ID(s) |
+|----|------------------------|---------------------------------------|--------------|
+| 1  | General Considerations | Wrong Covid Prediction                | 1            |
+| 2  | Intended Use           | Wrong Covid Prediction                | 1            |
+| 3  | Usability Test         | User misunderstands prediction result | 1            |
+
+
+## 2. Failure Modes
+
+> This is a list of stuff which can go wrong in your software. You should be able to come up with things while
+> you write code and when you think about it. Typically, stuff which always can go wrong is 1) something
+> becomes unavailable, 2) something returns invalid data, 3) something gets hacked.
+
+> I've written some examples for the Covid predictor application which I cover in my videos - you don't have
+> to watch those for now. The idea is that it's an app which predicts whether a certain patient has Covid,
+> pretty magical. An obvious failure mode would be that the app either calculates wrong predictions on the
+> backend (ID 1), or the frontend displays the predictions wrongly (ID 2). They both lead to the same hazard
+> (ID 1) which is listed in the Hazards and Analysis table below.
+
+| ID | Software System | Failure Mode                       | Hazard ID(s) |
+|----|-----------------|------------------------------------|--------------|
+| 1  | Backend         | Wrong Covid Prediction             | 1            |
+| 2  | Frontend        | Covid Prediction displayed wrongly | 1            |
+
+## 3. Hazards and Analysis
+
+> This is a list of stuff which will subsequently happen after your software has failed. It's more about what
+> happens in the real world, not in your software. The 14971 wants you to analyze Hazards, Hazardous
+> Situations and Harms, so that's what you'll find in the table :)
+>
+> Here's what happens: In the beginning, there's a hazard, like a wrong Covid prediction. That hazard has a
+> certain probability to lead to the (next) hazardous situation, in this case 1% (0.01), in which the user
+> thinks he is healthy, but actually has Covid. You can estimate p1 with some medical knowledge, in this case
+> maybe the prevalence of Covid in your target population.
+>
+> Then, this hazardous situation may lead to a harm, in this case, disease progression - the user who got the
+> wrong Covid prediction (healthy) may actually have Covid and now stay at home instead of going to the
+> hospital. So the disease gets worse. Maybe only 10% (0.1, p2) of users will actually blindly trust my Covid
+> app - so not all of them will get disease progression. Again, estimate this based on your own data.
+>
+> Finally, you multiple p1 with p2, check your Risk Acceptance Matrix (see template for the risk management plan) which Probability
+> Category it is (in this case P4). Also check that matrix which severity that harm would be, I'm just
+> assuming it could be S2 here. Once you have your Probability (P) and Severity (S), check your matrix whether
+> that's acceptable. In this case, it's not.
+>
+> So we need a Risk Control Measure which is referenced here by ID (1). As we can see, it reduced the
+> probability to P3, but not the severity. But that's fine, because the P3 and S2 - combination is acceptable,
+> based on our Risk Acceptance Table.
+>
+> The next table contains the list of Risk Control Measures.
+
+| ID | Hazard                 | p1   | Hazardous Situation                      | p2  | Harm                | p1*p2 | P  | S  | Acceptable? | Comment | Risk Control ID(s) | P  | S  | Acceptable? |
+|----|------------------------|------|------------------------------------------|-----|---------------------|-------|----|----|-------------|---------|--------------------|----|----|-------------|
+| 1  | Wrong Covid prediction | 0.01 | User thinks he is healthy, but has Covid | 0.1 | Disease progression | 0.001 | P4 | S2 | No          |         | 1                  | P3 | S2 | Yes         |
+
+## 4. Risk Control Measures
+
+> This is the table of Risk Control Measures which was referenced from the Hazards and Analysis table
+> above. We've used the Risk Control Measure with (ID 1) to reduce the risk of disease progression. For that,
+> we came up with a procedure to check our prediction algorithm with test data before we ship it. That makes
+> sense and that should probably reduce the probability of wrong predictions. In this case, by 0.01 (10^-2,
+> I'm coming up with numbers here). It doesn't reduce the severity, of course - the harm is still disease
+> progression.
+
+> Note that the 14971 has three types of Risk Control Measures:
+> * Inherent Safety by Design
+> * Protective Measures
+> * Information for Safety
+>
+> Also note that, in simplified terms, Information for Safety must actually be displayed in your application
+> to have any effect. Like, not in the user manual, because nobody reads the manual.
+
+| ID  | Description | Type | Probability Reduction | Severity Reduction | Negative Influence on Device Safety / Performance Introduced by Mitigation Measure? | Verification Implementation | Verification Effectiveness |
+| --- | ----------- | ---- | --------------------- | ------------------ | ----------------------------------------- | --------------------------- | --------------------------- |
+| 1   | Check prediction algorithm with test data | Protective Measure | 10^-2 | 1 | No | Link Software Test ID | Link Usability Test ID |
+
+
+<!-- Links -->
+
+[wikipedia-fmea]: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis
diff --git a/openregulatory/templates/techdoc/62304/62304-mapping.md b/openregulatory/templates/techdoc/62304/62304-mapping.md
new file mode 100644
index 00000000..a5cd3454
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/62304-mapping.md
@@ -0,0 +1,105 @@
+# IEC 62304:2006 Mapping of Requirements to Documents
+
+This table maps all requirements of the IEC 62304:2006 (by section) to the relevant documents (here:
+OpenRegulatory templates).
+
+> Note that the document names in the "Fulfilled in Document" column are based on the OpenRegulatory
+> templates. You'll probably have a different system for assigning document names, so feel free to rename
+> them.
+
+| Classes   | Section | Title                                                                  | Fulfilled in Document                                                                          | Comment                                           |
+|-----------|---------|------------------------------------------------------------------------|------------------------------------------------------------------------------------------------|---------------------------------------------------|
+| (General) | 4.1     | Quality management system                                              | Quality Management Manual                                                                      |                                                   |
+|           | 4.2     | Risk management                                                        | SOP Integrated Software Development                                                            |                                                   |
+|           | 4.3     | Software Safety Classification                                         | Risk Management Report                                                                         |                                                   |
+|           | 4.4     | Legacy Software                                                        | (Not applicable)                                                                               | *Not applicable unless you have legacy software.* |
+| A, B, C   | 5.1.1   | Software development plan                                              | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 5.1.2   | Keep software development plan update                                  | SOP Integrated Software Development                                                            |                                                   |
+| A, B, C   | 5.1.3   | Software development plan reference to system design and development   | Software Development and Maintenance Plan                                                      |                                                   |
+| C         | 5.1.4   | Software development standards, methods and tool planning              | Software Development and Maintenance Plan                                                      |                                                   |
+| B, C      | 5.1.5   | Software integration and integration test planning                     | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 5.1.6   | Software verification planning                                         | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 5.1.7   | Software risk management planning                                      | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 5.1.8   | Documentation planning                                                 | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 5.1.9   | Software configuration management planning                             | Software Development and Maintenance Plan                                                      |                                                   |
+| B, C      | 5.1.10  | Supporting items to be controlled                                      | Software Development and Maintenance Plan                                                      |                                                   |
+| B, C      | 5.1.11  | Software configuration item control before verification                | Software Development and Maintenance Plan                                                      |                                                   |
+| B, C      | 5.1.12  | Identification and avoidance of common software defects                | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 5.2.1   | Define and document software requirements from system requirements     | SOP Integrated Software Development; Software Requirements List                                |                                                   |
+| A, B, C   | 5.2.2   | Software requirements content                                          | Software Requirements List                                                                     |                                                   |
+| B, C      | 5.2.3   | Include risk control measures in software requirements                 | Software Requirements List                                                                     |                                                   |
+| A, B, C   | 5.2.4   | Re-evaluate medical device risk analysis                               | SOP Integrated Software Development                                                            |                                                   |
+| A, B, C   | 5.2.5   | Update requirements                                                    | SOP Integrated Software Development                                                            |                                                   |
+| A, B, C   | 5.2.6   | Verify software requirements                                           | SOP Integrated Software Development; Checklist Software Requirements                           |                                                   |
+| B, C      | 5.3.1   | Transform software requirements into an architecture                   | SOP Integrated Software Development; (Software architecture diagrams, interface documentation) |                                                   |
+| B, C      | 5.3.2   | Develop an architecture for the interfaces of software items           | SOP Integrated Software Development; (Software architecture diagrams, interface documentation) |                                                   |
+| B, C      | 5.3.3   | Specify functional and performance requirements of SOUP item           | SOUP list                                                                                      |                                                   |
+| B, C      | 5.3.4   | Specify system hardware and software required by SOUP item             | SOUP list                                                                                      |                                                   |
+| C         | 5.3.5   | Identify segregation necessary for risk control                        | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 5.3.6   | Verify software architecture                                           | SOP Integrated Software Development; Checklist Software Architecture                           |                                                   |
+| B, C      | 5.4.1   | Subdivide software into software units                                 | SOP Integrated Software Development; (Software architecture diagrams)                          |                                                   |
+| C         | 5.4.2   | Develop detailed design for each software unit                         | SOP Integrated Software Development                                                            |                                                   |
+| C         | 5.4.3   | Develop detailed design for interfaces                                 | SOP Integrated Software Development                                                            |                                                   |
+| C         | 5.4.4   | Verify detailed design                                                 | SOP Integrated Software Development                                                            |                                                   |
+| A, B, C   | 5.5.1   | Implement each software unit                                           | SOP Integrated Software Development; (GitHub Pull Requests / GitLab Merge Requests)            |                                                   |
+| B, C      | 5.5.2   | Establish software unit verification process                           | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 5.5.3   | Software unit acceptance criteria                                      | SOP Integrated Software Development                                                            |                                                   |
+| C         | 5.5.4   | Additional software unit acceptance criteria                           | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 5.5.5   | Software unit verification                                             | SOP Integrated Software Development; (CI/CD in GitHub Pull Requests / GitLab Merge Requests)   |                                                   |
+| B, C      | 5.6.1   | Integrate software units                                               | SOP Integrated Software Development; (Merge in GitHub / GitLab)                                |                                                   |
+| B, C      | 5.6.2   | Verify software integration                                            | SOP Integrated Software Development; (Merge in GitHub / GitLab)                                |                                                   |
+| B, C      | 5.6.3   | Software integration testing                                           | SOP Integrated Software Development; (Merge in GitHub / GitLab, CI/CD)                         |                                                   |
+| B, C      | 5.6.4   | Software integration testing content                                   | SOP Integrated Software Development; (CI/CD in GitHub Pull Requests / GitLab Merge Requests)   |                                                   |
+| B, C      | 5.6.5   | Evaluate software integration test procedures                          | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 5.6.6   | Conduct regression tests                                               | SOP Integrated Software Development; (CI/CD in GitHub Pull Requests / GitLab Merge Requests)   |                                                   |
+| B, C      | 5.6.7   | Integration test record contents                                       | SOP Integrated Software Development; (CI/CD in GitHub Pull Requests / GitLab Merge Requests)   |                                                   |
+| B, C      | 5.6.8   | Use software problem resolution process                                | SOP Software Problem Resolution                                                                |                                                   |
+| A, B, C   | 5.7.3   | Retest after changes                                                   | SOP Integrated Software Development                                                            |                                                   |
+| A, B, C   | 5.7.4   | Evaluate software system testing                                       | SOP Integrated Software Development; Software System Test Plan                                 |                                                   |
+| A, B, C   | 5.7.5   | Software system test record contents                                   | SOP Integrated Software Development; Software System Test Protocol                             |                                                   |
+| A, B, C   | 5.8.1   | Ensure software verification is complete                               | SOP Integrated Software Development; Checklist Software Release                                |                                                   |
+| A, B, C   | 5.8.2   | Document known residual anomalies                                      | SOP Integrated Software Development; (Release notes / changelog)                               |                                                   |
+| B, C      | 5.8.3   | Evaluate known residual anomalies                                      | Risk table; (Release notes / changelog)                                                        |                                                   |
+| A, B, C   | 5.8.4   | Document released versions                                             | SOP Integrated Software Development; (Release notes / changelog)                               |                                                   |
+| B, C      | 5.8.5   | Document how released software was created                             | SOP Integrated Software Development; (Release notes / changelog)                               |                                                   |
+| B, C      | 5.8.6   | Ensure activities and tasks are complete                               | SOP Integrated Software Development; Checklist Software Release                                |                                                   |
+| A, B, C   | 5.8.7   | Archive software                                                       | SOP Integrated Software Development; (Tagged commit in git)                                    |                                                   |
+| A, B, C   | 5.8.8   | Assure reliable delivery of released software                          | SOP Integrated Software Development                                                            |                                                   |
+| A, B, C   | 6.1     | Establish a software maintenance plan                                    | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 6.2.1.1 | Monitor feedback                                                       |                                                                                                |                                                   |
+| A, B, C   | 6.2.1.2 | Document and evaluate feedback                                         |                                                                                                |                                                   |
+| A, B, C   | 6.2.1.3 | Evaluate problem report's affects on safety                            | SOP Problem Resolution                                                                         |                                                   |
+| A, B, C   | 6.2.2   | Use software problem resolution process                                | SOP Problem Resolution                                                                         |                                                   |
+| A, B, C   | 6.2.3   | Analyse change requests                                                | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 6.2.4   | Change request approval                                                | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 6.2.5   | Communicate to users and regulators                                    | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 6.3.1   | Use established process to implement modification                      | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 6.3.2   | Re-release modified software system                                    | SOP Change Management                                                                          |                                                   |
+| B, C      | 7.1.1   | Identify software items that could contribute to a hazardous situation | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 7.1.2   | Identify potential causes of contribution to a hazardous situation     | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 7.1.3   | Evaluate published SOUP anomaly lists                                  | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 7.1.4   | Document potential causes                                              | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 7.2.1   | Define risk control measures                                           | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 7.2.2   | Risk control measures implemented in software                          | SOP Integrated Software Development                                                            |                                                   |
+| B, C      | 7.3.1   | Verify risk control measures                                           | SOP Integrated Software Development                                                            |                                                   |
+|           | 7.3.2   | (Not used)                                                             |                                                                                                |                                                   |
+| B, C      | 7.3.3   | Document traceability                                                  | SOP Integrated Software Development; Software Requirements List                                |                                                   |
+| A, B, C   | 7.4.1   | Analyse changes to medical device software with respect to safety      | SOP Change Management                                                                          |                                                   |
+| B, C      | 7.4.2   | Analyse impact of software changes on existing risk control measures   | SOP Change Management                                                                          |                                                   |
+| B, C      | 7.4.3   | Perform risk management activities based on analyses                   | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 8.1.1   | Establish means to identify configuration items                         | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 8.1.2   | Identify SOUP                                                          | SOP Integrated Software Development                                                            |                                                   |
+| A, B, C   | 8.1.3   | Identify system configuration documentation                            | SOP Integrated Software Development                                                            |                                                   |
+| A, B, C   | 8.2.1   | Approve change requests                                                | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 8.2.2   | Implement changes                                                      | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 8.2.3   | Verify changes                                                         | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 8.2.4   | Provide means for traceability of change                               | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 8.3     | Configuration status accounting                                        | Software Development and Maintenance Plan                                                      |                                                   |
+| A, B, C   | 9.1     | Prepare problem reports                                                | SOP Software Problem Resolution                                                                |                                                   |
+| A, B, C   | 9.2     | Investigate the problem                                                | SOP Software Problem Resolution                                                                |                                                   |
+| A, B, C   | 9.3     | Advise relevant parties                                                | SOP Software Problem Resolution; SOP Incident Reporting                                        |                                                   |
+| A, B, C   | 9.4     | Use change control process                                             | SOP Change Management                                                                          |                                                   |
+| A, B, C   | 9.5     | Maintain records                                                       | SOP Software Problem Resolution                                                                |                                                   |
+| A, B, C   | 9.6     | Analyse problems for trends                                            | SOP Software Problem Resolution                                                                |                                                   |
+| A, B, C   | 9.7     | Verify software problem resolution                                     | SOP Software Problem Resolution                                                                |                                                   |
+| A, B, C   | 9.8     | Test documentation contents                                            | SOP Integrated Software Development                                                            |                                                   |
diff --git a/openregulatory/templates/techdoc/62304/algorithm-validation-report.md b/openregulatory/templates/techdoc/62304/algorithm-validation-report.md
new file mode 100644
index 00000000..ff008f38
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/algorithm-validation-report.md
@@ -0,0 +1,163 @@
+> DISCLAIMER:
+>
+> You may not need this template. It's aimed companies that develop devices including ML algorithms. Why do
+> they need this template?
+>
+> Due to the "blackbox" nature of many of those algorithms, their functionalities typically can't be verified
+> in the same sense as code reviews can verify correct coding in the world of old-school software
+> development. That's why they can only be validated by subjecting the model to rigorous testing on separate
+> test datasets. This report is the place to document all the results (e.g. sensitivity, specificity,
+> accuracy, ROC curve values, discussion of outlayers, edge cases, etc.). Side note: there's a disconnect
+> between what data science and regulatory affairs understands as validation and verification. Don't get
+> confused!
+
+# 1. General Information
+
+This document describes the specification of our machine learning (algorithm) model and its testing strategy.
+
+> Keep in mind that the results of the algorithm validation should also serve as input to and be referenced in
+> your clinical evaluation / performance evaluation report.
+
+**Regulatory references:**
+
+| ISO 13485:2016 Section   | Document Section |
+|--------------------------|------------------|
+| 6.2; 7.3.2               | 2.1              |
+| 7.3.7                    | 2.3; 3.1; 3.2    |
+| 4.2.3; 5.2; 7.2.1; 7.3.3 | 2.4              |
+| 4.1; 7.3.6               | 3                |
+| 7.3.2; 7.3.6; 7.3.7      | 5                |
+
+| ISO 14971:2019 Section | Document Section |
+|------------------------|------------------|
+| 4.3                    | 2.1              |
+| 5.2                    | 2.4              |
+
+| ISO 82304:2016 Section | Document Section |
+|------------------------|------------------|
+| 6.1                    | 2.1              |
+
+| ISO 62366-1:2015 Section | Document Section |
+|--------------------------|------------------|
+| 5.1; 5.2                 | 2.4              |
+
+| ISO 62304:2006 Section | Document Section |
+|------------------------|------------------|
+| 5.3; 8.1.2             | 2.2              |
+| 5.2                    | 2.4              |
+
+| ISO/IEC 24028:2020 Section | Document Section |
+|----------------------------|------------------|
+| 9.8.1; 10.5                | 3.1; 3.2         |
+| 9.8.2.1                    | 3.2              |
+| 9.8.2.2                    | 4                |
+
+**Relevant other documentation:**
+
+* SOP Software Development
+* Software Development and Maintenance Plan
+* SOUP List
+
+# 2. Development Resources
+
+For more context information, refer to the device’s software development and maintenance plan.
+
+## 2.1. Developer Team
+
+| Name  | Role  | Qualification |
+|-------|-------|---------------|
+| (...) | (...) | (...)         |
+
+## 2.2. SOUP / Frameworks
+
+| Name    | Version |
+|---------|---------|
+| PyTorch | (...)   |
+
+## 2.3. Data
+
+| Count | Description                                           |
+|-------|-------------------------------------------------------|
+|       | \<e.g. annotated heart rate dataset from a wearable\> |
+
+## 2.4. Development Planning
+
+Optional: remove or add to the following sub-paragraphs as appropriate.
+
+**Intended Purpose**
+
+> Reference intended use; describe intended task the model should solve.
+
+(...)
+
+**Clinical Environment**
+
+> Reference clinical evaluation plan; describe clinical context in which the model will be used.
+
+(...)
+
+**Software Architecture**
+
+> Reference software architecture (diagram); describe how the model will be embedded in the overall system and
+> how it will interact with other software components.
+
+(...)
+
+**Quality Requirements**
+
+> Reference clinical evaluation plan; describe quality criteria that shall apply to the model, for example,
+> quantify values for sensitivity / specificity, AUC, positive/negative predictive value, accuracy,
+> repeatability. Also, provide justification for why certain parameters may not apply and compare your
+> approach to the current state of the art / technology.
+
+(...)
+
+# 3. Data Management
+
+## 3.1. Data Acquisition
+
+> Describe how you acquired your data (sources, inclusion / exclusion criteria, possible biases, data
+> protection measures, etc). Give a rough estimate of what size of datasets are required.
+>
+> If applicable, reference relevant QMS processes.
+
+(...)
+
+## 3.2. Data Pre-Processing
+
+> Describe how you pre-processed data. Possible steps may include: anonymization / pseudonymization, removing
+> data elements, converting data formats or units, handling missing values or data outliers. How did you
+> divide data into training, validation and test data. If applicable, reference relevant QMS processes.
+
+(...)
+
+## 3.3. Data Annotation
+
+> Describe how data is labeled and how you determined the ground truth. Further, you can describe: labeling
+> requirements (quality criteria), qualification / training of staff involved, quality assurance for correct
+> labeling. If applicable, reference relevant QMS processes.
+
+(...)
+
+# 4. Algorithm Model Training and Description
+
+> Describe your algorithm model. For example: which type of model (e.g. CNN) is used? Optionally, add a graph
+> or diagram to explain the model architecture. Describe model training; e.g. selection of features, (most
+> important) hyperparameters, etc.
+
+(...)
+
+# 5. Algorithm Model Evaluation
+
+> Describe how testing is done: describe your test data set, which metrics are used for evaluation and which
+> values are deemed acceptable.
+
+(...)
+
+# 6. Conclusion
+
+> Discuss your evaluation results: why do they meet predefined quality criteria, why is the model fit for
+> purpose in accordance with the medical device’s intended use? Take into account possible risks, biases and
+> limitations.
+
+(...)
diff --git a/openregulatory/templates/techdoc/62304/bug-fixes-documentation-list.md b/openregulatory/templates/techdoc/62304/bug-fixes-documentation-list.md
new file mode 100644
index 00000000..0512dea8
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/bug-fixes-documentation-list.md
@@ -0,0 +1,28 @@
+# Bug Fixes Documentation List
+
+| Regulations          | Document Section |
+|----------------------|------------------|
+| IEC 62304, Chapter 9 | All              |
+
+## Summary
+
+This list is used to document the evaluation and implementation of all bug fixes according to the company's
+change management process.
+
+## Documentation of Bug Fixes
+
+| Evaluation Categories                                                         |                                                          |                                                      |       |
+|-------------------------------------------------------------------------------|----------------------------------------------------------|------------------------------------------------------|-------|
+| Bug ID                                                                        | #B01                                                     | #B02                                                 | (...) |
+| Bug Description                                                               | Hovering over button should display info box but doesn't | Users do not understand how to use text field        |       |
+| Occurrence Date and Time                                                      | 01-04-2021                                               | 16-03-2021                                           |       |
+| Corrective Action                                                             | Display of information when hovering                     | Renaming text field                                  |       |
+| Preventive Action                                                             | Added test scenario #T123 *(link file)*                  | Added usability test scenario #U123 *(link file)*    |       |
+| Affected Software Requirement                                                 | #REQ192 "Display user information (...)"                 | #REQ193 "Provide field to document information (..." |       |
+| Corresponding Implementation Ticket<br>*(optional, e.g. Github Pull Request)* | (...)                                                    | (...)                                                |       |
+| Corresponding Test Documentation<br>*(e.g. System Test ID #121)*              | #T123                                                    | #T132                                                |       |
+| Test Completed (When / By Whom)                                               | 2021-04-15 by John Doe                                   | 2021-04-15 by John Doe                               |       |
+| Affected Risk Documentation                                                   | -                                                        | Risk ID #369 "User does not understand XYZ"          |       |
+| Preliminary Incident Assessment by MDSO                                       | No incident                                              | No incident                                          |       |
+| Preliminary Significance Assessment by QMO                                    | Not significant                                          | Not significant                                      |       |
+| Release Date of Updated Software Version                                      | 2021-04-16                                               | 2021-04-16                                           |       |
diff --git a/openregulatory/templates/techdoc/62304/change-evaluation-list.md b/openregulatory/templates/techdoc/62304/change-evaluation-list.md
new file mode 100644
index 00000000..28e1348f
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/change-evaluation-list.md
@@ -0,0 +1,95 @@
+# Change Evaluation List
+
+| Regulation / Guidance                                             | Document Section |
+|-------------------------------------------------------------------|------------------|
+| Medical Device Directive, Annex II<br>Section 3.4 and Section 4.4 | All              |
+| Medical Device Regulation, Annex IX<br>Chapter II Section 4.10    | All              |
+| MDCG Guidance Document 2020-03                                    | All              |
+| EK-Med 3.9 B31                                                    | All              |
+
+## Summary:
+
+This list is used to document the evaluation of all regular change requests according to the company's change
+management process.
+
+## Evaluation of Product Changes
+
+> Disclaimer for Use #1: You may want to separate your lists for product and organizational changes, as you
+> should release a new list for every product version. This is to separately identify all changes related to
+> that specific version. Each product version list should ideally be attached to the respective technical
+> documentation file.
+
+> Disclaimer for Use #2: If any of the below mentioned categories are answered with YES, this indicates that
+> your change must be classified as significant.
+
+> Disclaimer for Use #3: In the example content filled into the table below, "PCR" stands for "Product Change
+> Request" and "OCR" stands for "Organization Change Request".
+
+**Please note:**
+
+* YES in the first two categories (intended use / essential requirements / GSPR) always leads to a significant
+  change.
+* If the device is modified (a) to correct an error, for which there is a safety risk to the patient if the
+  error is not corrected or (b) as part of field safety corrective actions for an incident, the change is
+  discussed with the Notified Body to determine the significance of the change. If no Notified Body was
+  involved in the conformity assessment process of the device, the change is treated as a significant change.
+
+| Evaluation Categories                                                                                                                                                                                                                      |                                                                              |                                                                |       |
+|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------|----------------------------------------------------------------|-------|
+| **Change Request ID**                                                                                                                                                                                                                      | #PCR01                                                                       | #PCR02                                                         | (...) |
+| **Change Request Description**                                                                                                                                                                                                             | Performance update of machine learning algorithm model                       | Additional integrability of device with new clinical IT-system |       |
+| **Overall Evaluation Outcome**                                                                                                                                                                                                             | **Not significant**                                                          | **Significant**                                                |       |
+| Does the change alter specifications provided in the Intended Use?<br>(Chart A of MDCG 2020-03, e.g. new user or patient population)                                                                                                       | No                                                                           | No                                                             |       |
+| Does the change affect conformity with the Essential Requirements (MDD) / General Safety and Performance Requirements (MDR)?<br>(EK-Med 3.9 B31, Section 5.1)                                                                              | No                                                                           | No                                                             |       |
+| Does change implementation require further clinical or usability data to support safety and performance?<br>(Chart B of MDCG 2020-03)                                                                                                      | No, but internal validation showed that performance on same metrics improved | Yes                                                            |       |
+| Do new risks require risk control measures or are existing risks negatively affected?<br>(Chart B of MDCG 2020-03)                                                                                                                         | No                                                                           | Yes                                                            |       |
+| Does the change alter built-in control mechanisms or alarms? (Chart B of MDCG 2020-03)                                                                                                                                                     | No                                                                           | No                                                             |       |
+| Does the change modify an operating principle or sources of energy?<br>(Chart B of MDCG 2020-03)                                                                                                                                           | No                                                                           | No                                                             |       |
+| Does the change introduce a new or major change of the operating system or of any component?<br>(Chart C of MDCG 2020-03, e.g. major SOUP update)                                                                                          | No                                                                           | No                                                             |       |
+| Does the change introduce a new or modified architecture or database structure, change of an algorithm? (Chart C of MDCG 2020-03, e.g. changes to prediction principle of an algorithm model)                                              | No, same prediction model                                                    | No                                                             |       |
+| Does the change replace previously required user input by a closed-loop algorithm?<br>(Chart C of MDCG 2020-03)                                                                                                                            | No                                                                           | No                                                             |       |
+| Does the change introduce a new diagnostic or therapeutic feature, or new channel of interoperability?<br>(Chart C of MDCG 2020-03)                                                                                                        | No                                                                           | Yes, new channel of interoperability                           |       |
+| Does the change introduce a new user interface or presentation of data? (Chart C of MDCG 2020-03)                                                                                                                                          | No                                                                           | No                                                             |       |
+| Does change implementation involve changes in critical suppliers?<br>(Chart D of MDCG 2020-03)                                                                                                                                             | No                                                                           | No                                                             |       |
+| Does the change impact the way medical data is read or interpreted by the user, such that the treatment or diagnosis of the patient may be altered when compared to the previous version of the software?<br>(EK-Med 3.9 B31, Section 5.4) | Yes, but only improved accuracy in supported diagnosis                       | No                                                             |       |
+
+## Evaluation of Organizational Changes
+
+Please note: YES in the first two categories (essential requirements / GSPR) always leads to a significant
+change.
+
+| Evaluation Categories                                                                                                                                                                                                                                                                                                        |                                    |                                                                        |       |
+|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------|------------------------------------------------------------------------|-------|
+| **Change Request ID**                                                                                                                                                                                                                                                                                                        | #OCR1                              | #OCR2                                                                  | (...) |
+| **Change Request Description**                                                                                                                                                                                                                                                                                               | Change of Company Business Address | Adding a new compliance process to comply with anti-bribery provisions |       |
+| **Overall Evaluation Outcome**                                                                                                                                                                                                                                                                                               | **Significant**                    | **Not significant**                                                    |       |
+| Does the change affect QMS conformity with the Essential Requirements (MDD) / General Safety and Performance Requirements (MDR)? (EK-Med 3.9 B31, Section 5.2)                                                                                                                                                               | No                                 | No                                                                     |       |
+| Does the change affect product conformity with the Essential Requirements (MDD) / General Safety and Performance Requirements (MDR) or the approved type / design?<br>(EK-Med 3.9 B31, Section 5.2)                                                                                                                          | No                                 | No                                                                     |       |
+| Does the change relate to manufacturing processes, technologies, facility or equipment in a way that could impact product safety and performance? (EK-Med 3.9 B31, Section 5.2)                                                                                                                                              | No                                 | No                                                                     |       |
+| Does the change affect the location of the company's activities?<br>(EK-Med 3.9 B31, Section 5.2)                                                                                                                                                                                                                            | Yes                                | No                                                                     |       |
+| Does change implementation involve changes in critical suppliers?<br>(Chart D of MDCG 2020-03; EK-Med 3.9 B31, Section 5.2)                                                                                                                                                                                                  | No                                 | No                                                                     |       |
+| Does the change affect the arrangements implemented to achieve continued compliance of the QMS with the relevant harmonized standards and/or MDD/MDR requirements (e.g. design verification, design validation, organizational structure, process interaction, quality control procedures)?<br>(EK-Med 3.9 B31, Section 5.2) | No                                 | No                                                                     |       |
+
+> Based on the linked guidance documents, examples for non-significant changes are:
+>
+> * a software change that only introduces non-therapeutic and/or non-diagnostic features such as printing,
+>   faxing, improved image clarity, reporting format or additional language support
+> * a software change that only modifies the appearance of the user interface with negligible risk of
+>   impacting the diagnosis or therapy delivered to the patient
+> * a software change only intended to correct an inadvertent logic error that does not pose a safety risk and
+>   brings the system back into specification
+> * a software change that consists only of tightening of design specifications within specified tolerances
+>   and where there is no creation of new features
+> * changes to labelling to include additional languages required in other regulatory jurisdictions
+> * minor changes to clarify the existing wording of warnings and precautions. However, in the case where
+>   these changes add or remove a contraindication, or remove a warning or precaution, the Notified Body shall
+>   be involved.
+
+
+> Based on the linked guidance documents, examples for significant changes are:
+>
+> * an alteration in software that modifies an algorithm impacting the diagnosis or the therapy delivered
+> * introduction or removal of a new alarm function from the software such that a response to the new
+>   configuration may change the treatment of the patient in comparison to the previous version of the
+>   software
+> * medical data is presented in a new format, new dimension or new measuring unit.
diff --git a/openregulatory/templates/techdoc/62304/checklist-software-release.md b/openregulatory/templates/techdoc/62304/checklist-software-release.md
new file mode 100644
index 00000000..7234b2a2
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/checklist-software-release.md
@@ -0,0 +1,45 @@
+# Checklist: Software Release
+
+| Classes | IEC 62304:2006 Section | Document Section |
+| ------- | ---------------------- | ---------------- |
+| A, B, C | 5.8.1 | (All) |
+| A, B, C | 5.8.2 | (All) |
+| A, B, C | 5.8.3 | (All) |
+| A, B, C | 5.8.4 | (All) |
+| B, C | 5.8.5 | (All) |
+| B, C | 5.8.6 | (All) |
+| A, B, C | 5.8.7 | (All) |
+
+## Summary
+
+This checklist is used to verify that documentation and activities are complete before releasing a new version of the product.
+
+> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The main point is that, at minimum, the items below should be checked (and documented) before you release a new version of your software.
+
+> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty much the bare minimum to be 62304-compliant.
+
+## Checklist
+
+The following documents are up to date:
+
+> The table below shows examples only. Add - or reference - a list of all your required TechDoc records.
+
+| Item | Yes | No | Comment |
+| ---- | --- | --- | ------- |
+| Device Description |  |  |  |
+| Clinical Evaluation |  |  |  |
+| Declaration of Conformity |  |  |  |
+| (...) |  |  |  |
+
+The following activities have been performed:
+
+| Item | Yes | No | Comment |
+| ---- | --- | --- | ------- |
+| All relevant functionalities of the software have been specified; the Software Requirement List is complete and has been reviewed. |  |  |  |
+| All relevant risks (including risks of known anomalies) have been evaluated; the Risk Management Report is complete. |  |  |  |
+| Verification (as software system testing) has been completed. |  |  |  |
+| Design control traceability is ensured:<br>Stakeholder requirements can be traced to software requirements.<br>Software requirements can be traced to system tests.<br>Software requirements can be traced to software code implementation / software code reviews.<br>Software requirements can be traced to risks and risk control measures.<br>Stakeholder requirements can be traced to usability tests.<br>Hazard-related use scenarios can be traced to usability tests.<br>Hazard-related use scenarios can be traced to risks and risk control measures. |  |  |  |
+| A version number as defined in the Software Development Plan has been assigned and added as a tag to git. |  |  |  |
+| Software is registered with a Notified Body. |  |  |  |
+| If release includes substantial change: Notified Body has been informed. |  |  |  |
+| Label is applied correctly including CE marking. |  |  |  |
diff --git a/openregulatory/templates/techdoc/62304/checklist-software-requirements-review.md b/openregulatory/templates/techdoc/62304/checklist-software-requirements-review.md
new file mode 100644
index 00000000..ec06d0ff
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/checklist-software-requirements-review.md
@@ -0,0 +1,43 @@
+# Checklist: Software Requirements Review
+
+| Classes | IEC 62304:2006 Section | Document Section |
+|---------|------------------------|------------------|
+| A, B, C | 5.2.6                  | (All)            |
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 7.3.3                  | (All)            |
+| 7.3.5                  | (All)            |
+
+## 1. Summary
+
+This checklist is used to review (verify) software requirements prior to implementation.
+
+> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill
+> this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The
+> main point is that, at minimum, the items below should be filled out before you start implementing software
+> requirements.
+
+> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty
+> much the bare minimum to be 62304-compliant.
+
+## 2. Checklist
+
+| Software Requirements...                                                      | Yes | No | Comment |
+|-------------------------------------------------------------------------------|-----|----|---------|
+| are traceable to design input or risk control measures.                       |     |    |         |
+| are complete.                                                                 |     |    |         |
+| are understandable, uniquely identifiable and do not contradict each other.   |     |    |         |
+| include user interface requirements (mockups, wireframes, etc.), if relevant. |     |    |         |
+| include IT security requirements, if relevant.                                |     |    |         |
+| are testable and include acceptance criteria.                                 |     |    |         |
+
+# 3. Comments
+
+\<Insert comments if applicable\>
+
+# 4. Result
+
+[ ] Software Requirements passed\
+[ ] Software Requirements not passed\
+[ ] Software Requirements passed with the following obligations: \<Insert if applicable\>\
diff --git a/openregulatory/templates/techdoc/62304/checklist-user-needs-review.md b/openregulatory/templates/techdoc/62304/checklist-user-needs-review.md
new file mode 100644
index 00000000..617075f7
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/checklist-user-needs-review.md
@@ -0,0 +1,39 @@
+# Checklist User Needs Review
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 7.3.2                  | (Al)             |
+
+| Classes | IEC 62304:2006 Section | Document Section |
+|---------|------------------------|------------------|
+| A, B, C | 5.1.8                  | (All)            |
+
+# 1. Summary
+
+With this checklist we verify the completeness and consistency of User Needs.
+
+Relevant documents:
+
+* User Needs (Doc-ID)
+
+# 2. Checklist
+
+| Checklist Items                                                                                                  | Yes | No | Comment |
+|------------------------------------------------------------------------------------------------------------------|-----|----|---------|
+| The user needs are complete.                                                                                     |     |    |         |
+| The user needs address all relevant stakeholders.                                                                |     |    |         |
+| The user needs take all relevant use scenarios of the intended use into account.                                 |     |    |         |
+| The user needs cover all relevant categories (e.g. technical, regulatory, organizational, market).               |     |    |         |
+| The user needs are not ambiguous, self-contradicting or conflicting with each other.                             |     |    |         |
+| The user needs are traceable.                                                                                    |     |    |         |
+| The user needs are testable (if required).                                                                       |     |    |         |
+
+# 3. Comments
+
+\<Insert comments if applicable\>
+
+# 4. Result
+
+[ ] User needs passed\
+[ ] User needs not passed\
+[ ] User needs passed with the following obligations: \<Insert if applicable\>\
diff --git a/openregulatory/templates/techdoc/62304/list-of-medical-devices.md b/openregulatory/templates/techdoc/62304/list-of-medical-devices.md
new file mode 100644
index 00000000..6a753119
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/list-of-medical-devices.md
@@ -0,0 +1,36 @@
+# 1. General Information
+
+This document describes the latest device details and as well as details for previous device versions.
+
+**Regulatory references:**
+
+* MDR Annex II Para. 1.2
+
+> Use this template to give you an idea of the necessary structure and contents. Ideally, this documentation
+> is maintained best in a spreadsheet / excel file format. Think of every heading as a separate sheet / tab.
+
+# 2. Current Medical Device Version
+
+> Fill out the table below for every installed device version. For example (in B2B business), use one row to
+> describe every customer site the software device is installed at.
+
+| Device Name           | Product Status                 | Release Date | Purpose               | Device Identifier (DI) | Product Identifier (PI) | Customer Details | Customer Point of Contact | App Store URL | Commentary |
+|-----------------------|--------------------------------|--------------|-----------------------|------------------------|-------------------------|------------------|---------------------------|---------------|------------|
+| \<enter device name\> | \<released / in trial / etc.\> | (...)        | \<e.g. clinical use\> | (...)                  | (...)                   | (...)            | (...)                     | (...)         | (...)      |
+|                       |                                |              |                       |                        |                         |                  |                           |               |            |
+
+# 3. Previous Versions
+
+> Use the table below to document your device's versions history.
+
+| Device Name           | Device Version | Release Date | Decommissioning Date | Device Identifier (DI) | Product Identifier (PI) | Commentary |
+|-----------------------|----------------|--------------|----------------------|------------------------|-------------------------|------------|
+| \<enter device name\> | V.1.1          | (...)        | (...)                | (...)                  | (...)                   | (...)      |
+| \<enter device name\> | V.1.0          | (...)        | (...)                | (...)                  | (...)                   | (...)      |
+|                       |                |              |                      |                        |                         |            |
+
+# 4. Similar Devices
+
+| Product Name          | Manufacturer | Country of Origin | Additional Information | Device Identifier (DI) |
+|-----------------------|--------------|-------------------|------------------------|------------------------|
+| \<enter device name\> | (...)        | (...)             | (...)                  | (...)                  |
diff --git a/openregulatory/templates/techdoc/62304/software-architecture-checklist.md b/openregulatory/templates/techdoc/62304/software-architecture-checklist.md
new file mode 100644
index 00000000..cf1c63aa
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/software-architecture-checklist.md
@@ -0,0 +1,34 @@
+# Software Architecture Checklist
+
+**Regulatory references:**
+
+IEC 62304, para. 5.3.6 [class B, C]
+
+**Relevant other documentation:**
+
+* SOP Software Development
+* User needs / stakeholder requirements
+* Design input / software requirements
+* Software architecture description
+* (...)
+
+# 1. Checklist
+
+| Criteria                                                                                                 | Pass / Fail             |
+|----------------------------------------------------------------------------------------------------------|-------------------------|
+| The software architecture is in agreement with the software requirements.                                | ( ) Yes<br>( ) Improve: |
+| All software systems are listed and their respective safety class is stated.                             | ( ) Yes<br>( ) Improve: |
+| All software components are listed and described, including interfaces.                                  | ( ) Yes<br>( ) Improve: |
+| All software units are listed and described.                                                             | ( ) Yes<br>( ) Improve: |
+| (Optional) Further architecture is described, e.g. databases, security and data protection requirements. | ( ) Yes<br>( ) Improve: |
+| The software architecture can be implemented with our given resources.                                   | ( ) Yes<br>( ) Improve: |
+
+# 2. Comments
+
+\<Insert comments if applicable\>
+
+# 3. Results
+
+( ) Software Architecture passed\
+( ) Software Architecture not passed\
+( ) Software Architecture passed with the following obligations: \<Insert if applicable\>\
diff --git a/openregulatory/templates/techdoc/62304/software-architecture-description.md b/openregulatory/templates/techdoc/62304/software-architecture-description.md
new file mode 100644
index 00000000..33f283c2
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/software-architecture-description.md
@@ -0,0 +1,87 @@
+# 1. Regulatory References
+
+**Regulatory references:**
+
+IEC 62304, para. 5.3.1 and 5.3.2 [class B, C]
+
+**Relevant other documentation:**
+
+* SOP Software Development
+* User needs / stakeholder requirements
+* Design input / software requirements
+* (...)
+
+# 2. Software Systems
+
+In compliance with DIN EN 62304, we subdivide our software on three levels: software systems, software
+components and software units.
+
+> Here, describe your internal software systems. The IEC 62304 defines those as an “integrated collection of
+> software items organized to accomplish a specific function or set of functions.”
+>
+> NOTE: Ideally, you would add an illustrating diagram to the Annex and reference it here.
+
+## 4.1. Frontend
+
+> Enter description, for example:
+>
+> * Function: user interface display
+> * Software safety classification and rationale
+> * Runtime
+> * Deployment
+> * User groups
+
+## 4.2. Backend
+
+> Enter description, for example:
+>
+> * Function: managing patient data and medical images.
+> * Software safety classification and rationale
+> * Runtime (e.g. JVM)
+> * Deployment (e.g. Docker container)
+> * User group
+
+## 4.3. Algorithm
+
+> Enter description, for example:
+>
+> * Function: taking medical images as input and output a prediction.
+> * Software safety classification and rationale
+> * Runtime (e.g. JVM)
+> * Deployment (e.g. Docker container)
+> * User group
+
+# 6. Software Units
+
+> Describe your internal software units. The IEC 62304 defines those as a “software item [any identifiable
+> part of a program, i.e. source code, object code, control code, control data, etc.] that cannot be
+> subdivided into other items”. For example:
+>
+> * Wearable device poller (regularly checks whether wearable device has new data and downloads it)
+> * Notification service (sends messages to Apple / Google for push notifications of mobile apps)
+> * (...)
+
+# 7. Database
+
+> Describe your databases. For example:
+>
+> * Relational database: Postgres v14
+
+# 8. IT Security
+
+## 8.1. Encryption of data
+
+\<enter content\>
+
+### 8.1.1. Data at rest
+
+\<enter content\>
+
+### 8.1.2. Data in transit
+
+> Example content:
+>
+> * Data in transit is encrypted with state-of-the-art encryption, e.g. SSL, TLS.
+> * Additionally, we create a Virtual Private Network (VPC) which prevents the Compute Instances from being
+>   exposed to the public internet. The algorithm and the database are therefore not publicly reachable; they
+>   are only reachable by the backend.
diff --git a/openregulatory/templates/techdoc/62304/software-development-maintenance-plan.md b/openregulatory/templates/techdoc/62304/software-development-maintenance-plan.md
new file mode 100644
index 00000000..671fb641
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/software-development-maintenance-plan.md
@@ -0,0 +1,175 @@
+# Software Development and Maintenance Plan
+
+> This document is related to your product. You somehow need to associate it with it. The easiest way would be
+> to just put all product-related documents into a folder in your QMS so that the association is
+> clear. Alternatively, you could mention the related product and version here, but then you'd have to update
+> the version here any time you do a new release. Painful!
+
+This document summarizes development and maintenance activities.
+
+## Mapping of Standard Requirements to Document Sections
+
+| ISO 13485:2016 Section                | Document Section |
+|---------------------------------------|------------------|
+| 7.3.2 Design and Development Planning | 1, 2, 3, 7       |
+
+| Classes | IEC 62304:2006 Section                                                     | Document Section |
+|---------|----------------------------------------------------------------------------|------------------|
+| A, B, C | 4.4.2 Risk Management Activities                                           | 1                |
+| A, B, C | 5.1.1 a) (Processes)                                                       | 1                |
+| A, B, C | 5.1.1 b) (Deliverables)                                                    | 1                |
+| A, B, C | 5.1.1 c) (Traceability)                                                    | 1                |
+| A, B, C | 5.1.1 d) (Configuration and Change Management)                             | 1, 5             |
+| A, B, C | 5.1.1 e) (Problem Resolution)                                              | 1                |
+| A, B, C | 5.1.2 Keep Software Development Plan Updated                               | 1                |
+| A, B, C | 5.1.3 Software Development Plan Reference to System Design and Development | 2                |
+| C       | 5.1.4 Software Development Standards, Methods and Tools Planning           |                  |
+| B, C    | 5.1.5 Software Integration and Integration Test Planning                   | 3, 8             |
+| A, B, C | 5.1.6 Software Verification Planning                                       | 7                |
+| A, B, C | 5.1.7 Software Risk Management Planning                                    | 1                |
+| A, B, C | 5.1.8 Documentation Planning                                               | 6                |
+| A, B, C | 5.1.9 Software Configuration Management Planning                           | 5                |
+| B, C    | 5.1.10 Supporting Items to be Controlled                                   | 5                |
+| B, C    | 5.1.11 Software Configuration Item Control Before Verification             | 5                |
+| B, C    | 5.1.12 Identification and Avoidance of Common Software Defects             | 4                |
+| A, B, C | 6.1 Software Maintenance Plan.                                             | 9                |
+
+## 1 Relevant Processes and Documents
+
+Please see the relevant processes for the following activities:
+
+ * Risk management activities incl. SOUP risks: SOP Integrated Software Development
+ * Problem resolution: SOP Problem Resolution
+ * Software development incl. deliverables, traceability, regular update of software development plan: SOP
+   Integrated Software Development
+ * Change management: SOP Change Management
+ * SOUP List
+ * SOP Usability Engineering
+
+## 2. Required Resources
+
+### 2.1 Team
+
+| Role               | Count | Names                    |
+|--------------------|-------|--------------------------|
+| Frontend Developer | 2     | Ada Lovelace, Steve Jobs |
+| Backend Developer  | 1     | Alan Turing              |
+
+### 2.2 Software
+
+Describe your device's software safety class according to IEC 62304 and your reasoning behind the classification.
+
+#### Programming Languages
+
+> List the languages you’ll be using, including compiler and language versions.
+
+| Name   | Version |
+|--------|---------|
+| Python | 3.8     |
+
+#### Development Software
+
+> List software used to support development, e.g., IDEs.
+
+| Name    | Version  |
+|---------|----------|
+| PyCharm | 2020.1.4 |
+
+### 2.3 System Requirement / Target Runtime
+
+> List your target runtime(s).
+
+| Name    | Version |
+|---------|---------|
+| CPython | 3.8     |
+
+> Specify system requirements, e.g., the minimum specifications of the server / compute instance you'll be
+> running your software on
+
+*Minimum system requirements:*
+
+ * *Server-grade dual-core CPU, e.g., Intel Xeon E3-1230 v5 or higher*
+ * *4 GB of RAM*
+ * *1 GBit/s up- and downlink*
+ * *20GB SSD storage*
+
+## 3 Design Phases
+
+> The 13485 requires you to specify "Design Phases". Here are some suggestions which you could use.
+
+| Title          | Date | Description |
+|----------------|------|-------------|
+| Specification  |      |             |
+| Implementation |      |             |
+| Testing        |      |             |
+| Validation     |      |             |
+| Release        |      |             |
+
+## 4 Avoiding Common Software Defects Based on Selected Programming Technology
+
+> Discuss how your selected programming technology may introduce risks and how you plan to avoid them. With
+> modern, dynamically-typed languages, an obvious risk is that you encounter runtime exceptions. So you could
+> argue that your test coverage is great and compensates for that. You could also link to your risk analysis
+> here if you analyse those risks further.
+
+## 5 Configuration Management and Version Control
+
+> Describe which version control software you're using (probably git, like all human beings on this planet
+> right now, except enterprise developers). Also describe your branching model, i.e., how your developers
+> create branches during development, how you name them and how you merge them (pull requests? merge commits?
+> squash before?). Your code review will be described in the next section.
+>
+> Importantly, describe which things (code, build files, etc.) are put in version control. Describe how you
+> name versions and how you tag them. Your goal should be that you can retrieve an old version and build
+> it. Why? Something with a newer version may go wrong (harm patients) and you may need to roll back.
+
+*git is used as version control software. All source code and build files are committed to version control.*
+
+*When implementing software requirements, developers create a new branch starting at master. During
+development, developers may create intermediate commits on this development branch.*
+
+*When implementation is completed, a new merge commit to master is created.*
+
+***This is also the activity which constitutes integration of software units.***
+
+*For each release, the goal is to be able to uniquely identify it and retrieve all relevant files (code,
+configuration files like build scripts, SOUPs, etc.) at any time in the future.*
+
+*When a new software version is released, its commit is tagged in git. The tag is constructed by adhering to
+semver ([semver.org](https://semver.org)) 2.0.0 which results in a version of format MAJOR.MINOR.PATCH,
+e.g., 1.0.0.*
+
+## 6 Documentation Activities
+
+> Describe your policy on what should be documented while you develop software. Maybe you want to require
+> your developers to document all methods which are private. Maybe you want to keep an up-to-date software
+> architecture diagram in the repository, etc.
+
+## 7 Implementation Verification Activities
+
+> Describe verification activities, e.g. code review.
+
+*For each pull request, a code review is performed by a team member who was not the main author of the code
+under review. The code review is only marked as "approved" if the code complies with the code review
+criteria. This is:*
+
+ * *Code fulfils the software requirements*
+ * *Adherence to [PEP8 Style Guide](https://www.python.org/dev/peps/pep-0008/)*
+
+## 8 Software System Test Activities
+
+> Describe software system test activities. This could be continuous integration which is triggered by opening
+> a pull request (e.g. Travis CI, Circle CI). Describe what is tested and how that automated system works.
+
+*Integration tests are included in software system tests.*
+
+## 9 Validation Activities
+
+Validation is carried out as formative and summative usability evaluation as described in the software development process. A usability evaluation file (plan, protocol and report) will be prepared.
+
+## 10 Maintenance Activities
+
+> Describe how often you check SOUP issue trackers and how you document them.
+
+*SOUP issue trackers are checked at least once every 6 months. The verification date is updated in the SOUP
+list accordingly.*
diff --git a/openregulatory/templates/techdoc/62304/software-requirements-list.md b/openregulatory/templates/techdoc/62304/software-requirements-list.md
new file mode 100644
index 00000000..2c503194
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/software-requirements-list.md
@@ -0,0 +1,49 @@
+# Software Requirements List
+
+> This document is related to your product. You somehow need to associate it with it. The easiest way would be
+> to just put all product-related documents into a folder in your QMS so that the association is
+> clear. Alternatively, you could mention the related product and version here, but then you'd have to update
+> the version here any time you do a new release. Painful!
+
+> This is a list of your software requirements. If you have multiple software systems (you probably have a
+> backend and a frontend), you can use the "Software System" column. The categories are the 62304 categories
+> from section 5.2.2. *Risk Control Measure?* is just a yes/no field. And the related risk IDs refer to the
+> risk IDs from your risk table.
+
+> Of course, you could also use your own tool like Jira or GitHub issues. Just ensure that the content (i.e.,
+> the columns shown here) is roughly the same.
+
+## Mapping of Standard Requirements to Document Sections
+
+| Classes | IEC 62304:2006 Section | Document Section |
+|---------|------------------------|------------------|
+| A, B, C | 5.2.1, 5.2.2, 5.2.3    | 1                |
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 7.2.1                  | (All)            |
+| 7.3.3                  | (All)            |
+
+| IEC 62366-1:2015 Section | Title                                                                              | Document Section |
+|--------------------------|------------------------------------------------------------------------------------|------------------|
+| 5.2                      | Identify User Interface characteristics related to Safety and potential Use Errors | 1                |
+| 5.6                      | Establish User Interface Specification                                             | 1                |
+
+## 1. Software Requirements
+
+> While the 62034 "only" requires you to document Software Requirements, the 13485 also wants you to document
+> higher-level customer requirements. You could solve that by having a two-stage hierarchy of requirements: On
+> the first level, you'd have user stories (= the 13485 customer requirements), and beneath that, for each
+> user story, you'd have more technical specifications (= 62304 software requirements).
+
+> There's no great way to display this in a table, so for now, this table only solves the problem of defining
+> software requirements. Feel free to create a second table for user stories, or just cram them into this one
+> (good luck).
+
+| ID | Software System | Category       | Description                        | Risk Control Measure? | Related Risk IDs |
+|----|-----------------|----------------|------------------------------------|-----------------------|------------------|
+| 1  | App             | Functional     | On first launch, show introduction | No                    |                  |
+| 2  | App             | User Interface | Use user locale (language)         | No                    | 1 (Risk ID)      |
+| 3  | App             | Functional     | Average CPU usage < 2%             | No                    |                  |
+| 4  | Backend         | Security       | Store passwords as hashes          | Yes                   |                  |
+| 5  | Backend         | Interface      | Expose a REST API, handle JSON     | No                    |                  |
diff --git a/openregulatory/templates/techdoc/62304/sop-change-management.md b/openregulatory/templates/techdoc/62304/sop-change-management.md
new file mode 100644
index 00000000..5e5f5750
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/sop-change-management.md
@@ -0,0 +1,115 @@
+# SOP Change Management
+
+| Classes | IEC 62304:2006 Section | Document Section |
+|---------|------------------------|------------------|
+| A, B, C | 6.2.3                  | 2                |
+| A, B, C | 6.2.4                  | 2                |
+| A, B, C | 6.2.5                  | 2                |
+| A, B, C | 6.3.1                  | 3                |
+| A, B, C | 6.3.2                  | 3                |
+| A, B, C | 7.4.1                  | 2                |
+| B, C    | 7.4.2                  | 2                |
+| B, C    | 7.4.3                  | 2                |
+| A, B, C | 8.2.1                  | 2                |
+| A, B, C | 8.2.2                  | 3                |
+| A, B, C | 8.2.3                  | 3                |
+| A, B, C | 8.2.4                  | 3                |
+| A, B, C | 9.4                    | (All)            |
+
+## Summary
+
+This SOP describes how we evaluate and make changes to our software after it’s released.
+
+## General Considerations
+
+### Feedback Classification
+
+Feedback is either classified as a **bug fix** or a **regular change request**:
+
+* **Bug fixes:** By definition, bug fixes only constitute minor changes to the software code and complement
+  existing device features instead of introducing new ones or removing existing ones. Bug fixes must
+  not 1) Constitute significant changes to the medical device as defined by the criteria outlined in the
+  change assessment list and 2) Introduce new risks or failure modes
+* **Regular Change Requests:** All other changes that are not classified as a bug fix.
+
+### Guidance Documents
+
+The processing of changes is based on the following regulatory provisions and guidances:
+
+* **Medical Device Directive, Annex II Section 3.4 and Section 4.4**
+* **Medical Device Regulation, Annex IX Chapter II Section 4.10:** *"Changes to the approved device shall
+  require approval from the notified body which issued the EU technical documentation assessment certificate
+  where such changes could affect the safety and performance of the device or the conditions prescribed for
+  use of the device. Where the manufacturer plans to introduce any of the above-mentioned changes it shall
+  inform the notified body which issued the EU technical documentation assessment certificate thereof. The
+  notified body shall assess the planned changes and decide whether the planned changes require a new
+  conformity assessment in accordance with Article 52 or whether they could be addressed by means of a
+  supplement to the EU technical documentation assessment certificate. In the latter case, the notified body
+  shall assess the changes, notify the manufacturer of its decision and, where the changes are approved,
+  provide it with a supplement to the EU technical documentation assessment certificate."*
+* **Medical Device Coordination Group (MDCG) Document 2020-03:** “Guidance on significant changes regarding
+  the transitional provision under Article 120 of the MDR with regard to devices covered by certificates
+  according to MDD or AIMDD”
+* **EK-Med 3.9 B31** dated 11/2014 and **NBOG BPG 2014-3** dated 03/2014
+
+## Process Steps
+
+### 1. Creation of Change Request
+
+Changes proposals can originate from various sources, e.g.:
+
+* Internal design ideas
+* Market research
+* Customer feedback (see process for feedback management)
+* Post-Market Surveillance (see process for post-market surveillance)
+
+They can originate from anywhere inside the company.
+
+The Product Manager creates a change request ticket in the company’s project management software with a
+description of the proposed change.
+
+| Participants                                 |
+|----------------------------------------------|
+| Anyone in the company with a change proposal |
+
+| Input           | Output                                                   |
+|-----------------|----------------------------------------------------------|
+| Change proposal | Documented change request (ID per product version) |
+
+### 2. Evaluation of Change
+
+The Product Manager, together with a Regulatory Affairs Manager and the Head of Software Development, then
+evaluates the proposed change. In a first step, it is assessed if the change constitutes a bug fix or not. In
+case of a bug fix, the Product Manager directly proceeds with the evaluation as part of the bug fixes
+documentation list (link here).
+
+If the change does not constitute a bug fix but rather a regular change request, it is evaluated whether the
+change:
+
+1. Is a significant change (refer to e.g. MDCG 2020-03 for guidance)
+2. Introduces any new risks and whether those are acceptable
+3. Impacts any existing risk control measures
+4. Is technically feasible
+5. Makes sense for the product strategy of the company
+
+The evaluation is documented as part of the Change Evaluation List and results in a decision on whether the change is implemented and whether the Notified Body needs to be involved if the change is significant. These two decisions are documented in the change request ticket.
+
+If required, a Notified Body shall be informed before the implementation of changes. 
+Multiple proposed changes can be batched and discussed in one session.
+
+| Participants                 |
+|------------------------------|
+| Product Manager              |
+| Head of Software Development |
+| Regulatory Affairs Manager   |
+
+| Input          | Output                      |
+|----------------|-----------------------------|
+| Change request | Completed change evaluation |
+
+### 3. Implementation, Verification, Validation, Update of Documentation
+
+Change requests result as input to the SOP Software Development and are implemented accordingly.
+
+This includes verification, validation and release activities while ensuring traceability. The relevant
+documentation is updated and released with an updated declaration of conformity.
diff --git a/openregulatory/templates/techdoc/62304/sop-deployment.md b/openregulatory/templates/techdoc/62304/sop-deployment.md
new file mode 100644
index 00000000..19d46e63
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/sop-deployment.md
@@ -0,0 +1,153 @@
+# 1. General Information
+
+This SOP describes how we support the initial integration and update of integrations of our medical devices
+into the IT systems of our customers. Furthermore, it covers user management and user training. By following
+this process, we want to make sure that our customers receive our medical devices or services the intended
+way.
+
+> Obvious disclaimer!
+>
+> The deployment process should be very much customized to the context of your specific product. Are you
+> deploying your product web-based? Are you integrating with local healthcare providers' IT systems? Depending
+> on those questions, you will have to write each single process step of this template. Sorry to disappoint
+> you! Hope the structure helps you at least to get an idea of the regulatory requirements.
+
+**Regulatory references:**
+
+* ISO 13485:2016 Chapter 7.5
+
+**Relevant other documentation:**
+
+* Integration Evaluation Checklist (IECL)
+* Integration Validation Checklist (IVCL)
+* Software Requirement Specifications
+* List of Medical Devices (PROD)
+* User Training Strategy
+* Template User Training Record
+* User Consent Form (if applicable)
+
+## 1.1. Integration Specifications
+
+Integration Specifications are the technical requirements defined in the instructions for use as part of the
+technical documentation of medical devices.
+
+## 1.2. Integration Checklists
+
+The Integration Specifications are used to compile the Integration Evaluation Checklist. It is ensured that we
+do not offer medical devices or services which cannot be delivered by filling out this checklist, for which
+the Operations Team Representative is responsible. We fill out the Integration Validation Checklist after
+concluding integration work in order to validate if all technical requirements for successful integration have
+been completed.
+
+## 1.3. Device Traceability
+
+The operations team ensures that only released device versions are deployed to the customer
+environment. Deployment of device versions is documented as part of the medical device list. This file must
+contain at minimum:
+
+* Use description (e.g. clinical use, test, etc.)
+* Device description (e.g. device version, UDI, release date, identification number of the NB acc. to CE
+  certificate)
+* Company and contact data to a responsible person, deployment location
+
+## 1.4. Project Management Tool
+
+Optional:
+
+\<enter name\> is used as the project management tool to coordinate integration work.
+
+# 2. Process Overview
+
+## 2.1. Evaluation of Integration Requirements per Customer
+
+> Possible contents of this process step:
+>
+> * Following the draft of an offer / contract with a customer, the sales team reaches out to the technical
+>   operations team to evaluate if technical requirements are met.
+> * In coordination with competent staff on the customer’s side, the technical operations team gathers
+>   relevant information to fill out the integration evaluation checklist.
+> * If evaluation output does not allow for integration, the Operations team assesses other integration
+>   possibilities or recommends to not further pursue the customer contract.
+> * The operations team communicates the result of the evaluation to the sales team.
+
+(...)
+
+## 2.2. Integration Coordination
+
+> Possible contents of this process step:
+>
+> * Following integration evaluation and the conclusion of a new customer contract, the operations team is
+>   responsible to coordinate overall integration efforts.
+> * The operations team communicates to the customer (technical department) appropriate technical information
+>   and guidance for the integration.
+> * If integration problems occur, the operations team is responsible to (a) amend the integration evaluation
+>   checklist in order to prevent similar problems with future customers. (b) initiate the change management
+>   process in case the medical device itself needs to be changed.
+> * Successful integration is validated by filling out the integration validation checklist. The operations
+>   team obtains written confirmation of the customer setup after integration.
+> * The operations team informs the sales team once integration is complete. It documents the deployment date,
+>   deployed version of the device and customer information as part of the medical device list.
+
+(...)
+
+## 2.3. Algorithm Deployment and Configuration
+
+> Optional for ML-driven devices: after integration and before go-live, test the algorithm on
+> customer-specific live data (e.g. in the form of a “shadow mode” where algorithm results are not used in the
+> clinical setting yet). Evaluate the results together with users.
+
+(...)
+
+## 2.4. User Administration
+
+> Possible contents of this process step:
+>
+> * The operations team is responsible to activate users accounts according to the customer contract.
+> * No user account is activated without / before
+>   * Specification in the customer contract (e.g. number of seats?)
+>   * Full completion of previous process steps (e.g. algorithm test)
+>   * Optional to add here: user consent according to GDPR?
+
+(...)
+
+## 2.5. User Training
+
+> Possible contents of this process step:
+>
+> * The operations team is responsible to provide users with the instructions for use / user manual. If not
+>   part of the device, provision via email is sufficient.
+> * The operations team conducts user training as defined in the user training strategy and documents every
+>   training in the template for user training records.
+> * The operations team informs the sales and regulatory team about successfully completed training.
+
+(...)
+
+## 2.6. Handling of Feedback
+
+In case the operations team receives feedback (questions, complaints, praise, etc.) regarding the
+organization’s medical devices and services, it proceeds as outlined in the SOP feedback management.
+
+## 2.7. Handling of Updates
+
+> Possible contents of this process step:
+>
+> * In case of a version update, the operations team verifies if the integration requirements change due to
+>   the update and, if necessary, implements changes accordingly.
+> * The operations team coordinates updates with the customer prior to deployment and, if applicable, notifies
+>   the customer of potential product downtime according to the timeframe stated in customer contracts.
+> * After deployment, the latest deployed version is documented in the medical device list.
+
+(...)
+
+## 2.8. Handling of Terminated Contracts
+
+> Possible contents of this process step:
+>
+> * The sales team notifies the operations team in case of a terminated contract. Thereafter, the operations
+>   team is responsible for deactivating respective user accounts.
+> * The medical device list is updated accordingly.
+> * If required, the operations team is responsible to support the customer with necessary data migration and
+>   archives data related to the respective customer according to GDPR requirements (reference privacy policy
+>   or similar here).
+
+(...)
diff --git a/openregulatory/templates/techdoc/62304/sop-integrated-software-development.md b/openregulatory/templates/techdoc/62304/sop-integrated-software-development.md
new file mode 100644
index 00000000..c90c5ce7
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/sop-integrated-software-development.md
@@ -0,0 +1,381 @@
+# SOP Integrated Software Development
+
+| Classes | IEC 62304:2006 Section | Document Section |
+|---------|------------------------|------------------|
+| A, B, C | 5.1.2                  | 4                |
+| A, B, C | 5.2.1                  | 4                |
+| A, B, C | 5.2.4                  | 3, 7, 10         |
+| A, B, C | 5.2.5                  | 4                |
+| A, B, C | 5.2.6                  | 5                |
+| B, C    | 5.3.1                  | 6                |
+| B, C    | 5.3.2                  | 6                |
+| C       | 5.3.5                  |                  |
+| B, C    | 5.3.6                  | 6                |
+| B, C    | 5.4.1                  | 6                |
+| C       | 5.4.2                  |                  |
+| C       | 5.4.3                  |                  |
+| C       | 5.4.4                  |                  |
+| A, B, C | 5.5.1                  | 6                |
+| B, C    | 5.5.2                  | 7                |
+| B, C    | 5.5.3                  | 7                |
+| C       | 5.5.4                  |                  |
+| B, C    | 5.5.5                  | 7                |
+| B, C    | 5.6.1                  | 7                |
+| B, C    | 5.6.2                  | 7                |
+| B, C    | 5.6.3                  | 8                |
+| B, C    | 5.6.4                  | 8                |
+| B, C    | 5.6.5                  | 8                |
+| B, C    | 5.6.6                  | 8                |
+| B, C    | 5.6.7                  | 8                |
+| A, B, C | 5.7.3                  | 8                |
+| A, B, C | 5.7.4                  | 8                |
+| A, B, C | 5.7.5                  | 8                |
+| A, B, C | 5.8.1                  | 7                |
+| A, B, C | 5.8.2                  | 11               |
+| A, B, C | 5.8.4                  | 11               |
+| B, C    | 5.8.5                  | 11               |
+| B, C    | 5.8.6                  | 11               |
+| A, B, C | 5.8.7                  | 11               |
+| A, B, C | 5.8.8                  | 11               |
+| A, B, C | 6.1                    | 4                |
+| B, C    | 7.1.1                  | 2, 3, 6, 8, 10   |
+| B, C    | 7.1.2                  | 2, 3, 6, 8, 10   |
+| B, C    | 7.1.3                  | 6, 12            |
+| B, C    | 7.1.4                  | 2, 3, 6, 8, 10   |
+| B, C    | 7.2.1                  | 2, 3, 6, 8, 10   |
+| B, C    | 7.2.2                  | 2, 3, 6, 8, 10   |
+| B, C    | 7.3.1                  | 7                |
+| B, C    | 7.3.3                  | 9                |
+| A, B, C | 8.1.2                  | 4, 6, 8          |
+| A, B, C | 8.1.3                  | 11               |
+| A, B, C | 9.8                    | 8                |
+
+| ISO 14971:2019 Section | Document Section         |
+|------------------------|--------------------------|
+| 4.1                    | 3, 4, 5, 6, 8, 9, 10, 11 |
+| 5.1                    | 3, 4, 5, 6, 8, 9, 10, 11 |
+| 5.3                    | 3, 4                     |
+| 5.4                    | 3, 4                     |
+| 5.5                    | 3, 4                     |
+| 6                      | 3, 4                     |
+| 7.1                    | 3, 4, 5                  |
+| 7.2                    | 6                        |
+| 7.3                    | 6, 10                    |
+| 7.4                    | 10                       |
+| 7.5                    | 6                        |
+| 7.6                    | 10                       |
+| 8                      | 10                       |
+| 9                      | 10                       |
+
+| IEC 62366-1:2015 Section | Title                                                                  | Document Section |
+|--------------------------|------------------------------------------------------------------------|------------------|
+| 4.1.1                    | Usability Engineering Process                                          | (All)            |
+| 5.1                      | Prepare Use Specification                                              | 4                |
+| 5.8                      | Perform User Interface design, implementation and Formative Evaluation | 4, 5, 6, 7       |
+
+## Summary
+
+This SOP describes how software as a medical device is developed. It integrates risk management and usability
+engineering activities into the process.
+
+## General Notes
+
+### Integrated Process, Evolutionary Strategy
+
+This process integrates risk management and usability evaluation activities into the software development
+process. It, therefore, covers requirements of IEC 62304, ISO 14971 and IEC 62366. There are no separate risk
+management and usability engineering processes.
+
+The Software Development Process described in this SOP resembles an "evolutionary" strategy (IEC 62304:2006,
+Annex B), acknowledging that the user need is not fully understood and not all requirements are defined up
+front. Whenever requirements change, the preceding process steps and their outputs need to be re-done to
+ensure consistent and complete documentation.
+
+## Process Steps
+
+### 1. Design Input
+
+Based on business input and product ideas, the process for product certification and registration is initiated to create an initial device description (incl. medical device classification and software safety classification) and high-level vision for the planned product. Technical input is considered to assess whether the idea is feasible.
+
+Business input could be:
+
+ * Conversations with prospective customers
+ * Market opportunities
+ * Internal ideas
+
+Changes to the product also enter the process here (i.e., as a change request as defined in SOP Change
+Management).
+
+| Participants |
+|--------------|
+| CEO          |
+| CTO          |
+| CPO          |
+
+| Input           | Output             |
+|-----------------|--------------------|
+| Business input  | Device Description |
+| Technical input | Vision document    |
+| Product ideas   |                    |
+| Change Request  |                    |
+
+### 2. Usability Engineering and Risk Management Planning
+
+The risk management and usability engineering activities are planned and documented.
+
+The Risk Management Plan defines criteria for risk acceptability in the form of a risk policy and a risk acceptance matrix. It defines risk acceptability both for individual risks and the overall residual risk. The risk acceptance matrix is created by performing the following steps:
+* Estimate product usage over its lifetime
+* Define categories for the severity of harm (for example, categories may range from zero harm to death of a patient)
+* Define probability categories (for example, categories may range from ‘unthinkable’ over ‘rare’ to ‘certain’).
+* Start by defining the least probable category which has an absolute occurrence number of less than one. From there on, the more frequently occurring categories are added with probability increments of 10^2.
+* Create the risk acceptance matrix and define which combinations of the categories are deemed acceptable. Use color coding: red combinations represent unacceptable risks; yellow combinations represent risks that are acceptable.
+* Note: no fields are marked as green as all risks must be reduced as far as possible.
+
+The Usability Evaluation Plan includes summative and formative usability evaluation activities.
+
+| Participants                            |
+|-----------------------------------------|
+| CPO                                     |
+| Subject matter experts, e.g. physicians |
+
+| Input              | Output                                        |
+|--------------------|-----------------------------------------------|
+| Device description | Risk Management Plan                          |
+|                    | Usability Evaluation Plan                     |
+
+### 3. First Risk and Usability Assessment
+
+In the first risk and usability assessment, a preliminary hazard analysis is conducted and an initial risk
+table is drafted.
+
+Risk analysis is performed by conducting a Failure Mode and Effects Analysis (FMEA). This analysis includes the following
+activities:
+
+ * Identifying potential failure modes
+ * Identifying potential hazards, hazardous situations and harms in collaboration with subject matter experts (e.g. physicians)
+ * Estimating probabilities for the identified items and analyzing the severity of each harm, taking into account international standards, scientific studies, public reports, expert opinions and usability data.
+ * For software devices, the probability of occurrence of a hazard is assumed as 100%. The probability of each hazard leading to a hazardous situation and that leading to a harm must be estimated separately as part of the risk analysis. Multiplied, they present the overall probability per risk. In combination, overall probability of occurrence and the severity of harm are evaluated against the risk policy previously defined for the device.
+
+If a risk is deemed unacceptable based on our Risk Policy, it may be mitigated through Risk Control Measures in the priority as listed below.
+In general, we try to reduce the severity and probability of risks as far as possible (AFAP).
+
+1. Inherently safe design
+2. Protective measures in the device or development process
+3. Information for safety and/or training of users
+
+Further, a usability evaluation plan is created which covers future formative and summative usability evaluation
+activities.
+
+User needs with a focus on those related to hazards are specified. These will serve as input to the
+summative usability evaluation and are reviewed following the checklist for user needs review.
+
+| Participants                            |
+|-----------------------------------------|
+| CPO                                     |
+| Subject matter experts, e.g. physicians |
+
+| Input                     | Output                                          |
+|---------------------------|-------------------------------------------------|
+| Device description        | Preliminary Hazards Analysis                    |
+| Risk Management Plan      | Risk table incl. Risk Acceptance Matrix (draft) |
+| Usability Evaluation Plan | Software Safety Classification (draft)          |
+|                           | User Needs                                      |
+|                           | User Needs Review Checklist                     |
+
+### 4. Software Planning
+
+Based on the device description, the user needs and the preliminary risk analysis, the next step is to plan
+software development by defining software requirements. These also include the user interface specification,
+e.g. wireframes, mockups or style guides.
+
+A software development and maintenance plan is created following our template. Software versioning is to be specified in the plan and should typically follow semver, in a format: MAJOR.MINOR.PATCH.
+Significant changes will lead to major version changes and a change of the UDI-DI, while non-significant changes lead to minor version changes and changes of the UDI-PI only. Third-digit version changes (“patches”) result from bug fixes (see SOP Change Management and SOP Certification and Registration).
+
+The software system test plan is created based on the requirements. As requirements may change, the software
+system test plan is continuously updated to reflect those changes.
+
+Software requirements are verified through review by filling out the Checklist Software Requirements Review.
+
+| Participants       |
+|--------------------|
+| CTO                |
+| Software Engineer  |
+| Risk Manager       |
+| Usability Engineer |
+
+| Input                        | Output                                                   |
+|------------------------------|----------------------------------------------------------|
+| Device Description           | Software Development and Maintenance Plan                |
+| Vision Document              | Software Requirements incl. User Interface Specification |
+| Change Request               | Software System Test Plan                                |
+| Risk Table (draft)           | Risk Table (updated)                                     |
+| Preliminary Hazards Analysis |                                                          |
+
+### 5. First Review: Software Planning Review
+
+Software requirements are reviewed by following the checklist for Software Requirements Review. If the review is successful, move forward to the next step. If it's not, the software requirements have to be reworked with possible changes to the risk analysis and user needs. In that case, move back to the relevant step above.
+
+| Participants                            |
+|-----------------------------------------|
+| CTO                                     |
+| CPO                                     |
+| Risk Manager                            |
+| Usability Engineer                      |
+| Subject matter experts, e.g. physicians |
+
+| Input                 | Output                                              |
+|-----------------------|-----------------------------------------------------|
+| Software Requirements | Checklist Software Requirements Review (filled out) |
+| Risk Table (draft)    |                                                     |
+| User Needs            |                                                     |
+
+### 6. Software Architecture, Detailed Design and Implementation
+
+Software architecture is created (and detailed design, if necessary). As the software development process
+follows agile methodology, the software architecture may change as new knowledge is gained during
+implementation. The end result should be that both the implementation and the documented software architecture
+are synchronized.
+
+At a minimum, an architecture diagram showing all software systems including databases and networks is
+created. For each software system, public interfaces, are documented, e.g. REST APIs, internal methods.
+
+SOUP is added/updated here, if necessary. For each SOUP, we specify the name, version, manufacturer, website
+link (incl. release notes and issue tracker), requirements and prerequisites. SOUP must be verified before
+moving to the next step. Possible SOUP verification criteria include sufficient test coverage by the author
+and being commonly used; correct SOUP functioning is also verified through software verification and software
+system testing in the following steps.
+
+If new risks relating to software units and potential failure modes are discovered during this phase, they are
+added to the risk table.
+
+| Participants      |
+|-------------------|
+| CTO               |
+| Software Engineer |
+
+| Input                                     | Output                                     |
+|-------------------------------------------|--------------------------------------------|
+| Software Development and Maintenance Plan | Implemented Software Items, i.e. code      |
+| Software Requirements                     | Software Architecture (created/updated)    |
+| Software System Test Plan                 | Software Detailed Design (created/updated) |
+|                                           | SOUP list (created/updated)                |
+|                                           | Risk Table (updated)                       |
+
+### 7. Second Review, Verification, Formative Usability Evaluation, Integration
+
+The second review covers multiple activities:
+
+ * **Verification** of the software items based on code review and automated unit and integration tests
+ * **Formative Usability Evaluation** through a usability engineer whether the user interface has been
+   implemented as specified
+
+Code review is conducted based on the following criteria:
+
+ * Are all software requirements, software architecture and detailed design implemented correctly?
+ * Does the code adhere to coding guidelines which include requirements for documentation as specified in the
+   Software Development and Maintenance Plan?
+
+Upon successful verification, the implemented software requirement is integrated into the current code base as
+described in the Software Development and Maintenance Plan. The software units may be integrated only if all
+activities above were successful.
+
+| Participants       |
+|--------------------|
+| Software Engineer  |
+| Usability Engineer |
+
+| Input                                             | Output                                    |
+|---------------------------------------------------|-------------------------------------------|
+| Implemented Software Unit(s) incl. User Interface | Code review result                        |
+|                                                   | Unit / Integration test result(s)         |
+|                                                   | Formative Usability Evaluation Assessment |
+
+### 8. Software System Testing
+
+Based on the Software System Test Plan, software system tests covering all software requirements are
+performed.
+
+If new risks are discovered during the system tests, they are added to the risk table.
+
+If anomalies are encountered, they are added to the list of known anomalies and/or entered as new software
+requirements to be fixed.
+
+| Participants      |
+|-------------------|
+| Software Engineer |
+
+| Input                     | Output                            |
+|---------------------------|-----------------------------------|
+| Software System Test Plan | Software System Test Protocols    |
+|                           | Software System Test Report       |
+|                           | Risk Table (updated)              |
+|                           | List of known anomalies (updated) |
+
+### 9. Validation / Summative Usability Evaluation
+
+Validation is done as a summative usability evaluation.
+
+A Usability Test is conducted in the context of the actual user needs in accordance with the Usability
+Evaluation Plan.
+
+If new risks are discovered during the usability tests, they are added to the risk table.
+
+| Participants             |
+|--------------------------|
+| CPO          |
+| Usability Engineer       |
+| Users for Usability Test |
+
+| Input                                            | Output                      |
+|--------------------------------------------------|-----------------------------|
+| User Needs                                       | Usability Test Protocol(s)  |
+| Labeling and Instructions for Use, if applicable | Summative Evaluation Report |
+| Usability Evaluation Plan                        | Risk Table (updated)        |
+
+### 10. Final Risk Assessment and Risk-Benefit Analysis
+
+The overall risk of the product is evaluated by analyzing all identified risks so far. If unacceptable risks
+exist, they are weighed against the benefits of the Medical Device as part of the Clinical Evaluation SOP and as specified by the Clinical
+Evaluation Report. We only continue to release the Medical Device if the benefits outweigh the risks.
+
+If unacceptable risks remain which are not outweighed by the benefits, we consider adding new risk control
+measures and move back in to the relevant step in the process.
+
+The finalization of the Risk Management Report is the prerequisite for finalizing the Software Safety
+Classification.
+
+| Participants |
+|--------------|
+| CEO          |
+| CTO          |
+| CPO          |
+
+| Input                        | Output                                 |
+|------------------------------|----------------------------------------|
+| Preliminary Hazards Analysis | Risk Management Report                 |
+| Risk Table                   | Software Safety Classification (final) |
+| Clinical Evaluation          |                                        |
+| Software (Release Candidate) |                                        |
+
+### 11. Release
+
+Before release, it is ensured that all required processes (Software Development, Usability Evaluation, Risk
+Analysis) have been completed. Release notes are created which include the list of known anomalies. The
+software is only released if the remaining anomalies are deemed acceptable. A version number in accordance
+with the Software Development and Maintenance Plan is assigned.
+
+| Participants |
+|--------------|
+| CTO          |
+
+| Input                                     | Output                                      |
+|-------------------------------------------|---------------------------------------------|
+| Device Description                        | Released Software                           |
+| Checklist Release                         | Checklist Release (filled out)              |
+| Risk Analysis                             | Release Notes incl. list of known anomalies |
+| User Needs                                |                                             |
+| Software Requirements                     |                                             |
+| Software Architecture and Detailed Design |                                             |
+| Software Items incl. Verification         |                                             |
+| Software System Test Report               |                                             |
+| Usability Evaluation Results              |                                             |
diff --git a/openregulatory/templates/techdoc/62304/sop-software-problem-resolution.md b/openregulatory/templates/techdoc/62304/sop-software-problem-resolution.md
new file mode 100644
index 00000000..ff702ff9
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/sop-software-problem-resolution.md
@@ -0,0 +1,89 @@
+# SOP Software Problem Resolution
+
+| Classes | IEC 62304:2006 Section | Document Section |
+|---------|------------------------|------------------|
+| B, C    | 5.6.8                  | (All)            |
+| A, B, C | 6.2.1.3                | 1                |
+| A, B, C | 6.2.2                  | (All)            |
+| A, B, C | 9.1                    | 1                |
+| A, B, C | 9.2                    | 2                |
+| A, B, C | 9.3                    | 3                |
+| A, B, C | 9.5                    | 1                |
+| A, B, C | 9.6                    | 2                |
+| A, B, C | 9.7                    | 3                |
+
+## Summary
+
+This SOP describes how problems concerning our software product(s) are processed, evaluated and fixed.
+
+## Process Steps
+
+### 1. New Problem Evaluation
+
+New problems are entered as tickets into *\<your ticketing system\>*.
+
+Reported problems can originate from customers, users or company employees. Examples include customer feedback
+and bug reports.
+
+For each problem report, the following must be entered:
+
+ * Affected medical device and version
+ * Severity classification (see below)
+ * Problem description incl. instructions to reproduce
+
+We classify the severity of problems in the following categories:
+
+| Severity Classification | Description                                                      |
+|-------------------------|------------------------------------------------------------------|
+| High                    | Causes new or changed risks to patients which are unacceptable.  |
+| Medium                  | May cause new or changed risks to patients which are acceptable. |
+| Low                     | All other problems.                                              |
+
+For all problems classified as "Medium" or higher the person responsible for regulatory compliance must be
+informed who subsequently assesses it based on SOP Incident Reporting.
+
+> Under MDD, replace the Person Responsible for Regulatory Compliance with Safety Officer.
+
+| Participants                                 |
+|----------------------------------------------|
+| Head of product development                  |
+| Person responsible for regulatory compliance |
+
+| Input       | Output                                                  |
+|-------------|---------------------------------------------------------|
+| New problem | Problem report as *\<ticket in your ticketing system\>* |
+
+### 2. Root Cause Analysis and Procedure
+
+The root cause of the problem is determined (if possible) and a decision is made whether to fix it or not.
+
+We also analyze whether similar problems have occurred in the past and any trends can be discerned. If this is
+the case, it is noted in the problem report.
+
+| Participants                 |
+|------------------------------|
+| Head of software development |
+| Software developer           |
+
+
+| Input          | Output                                          |
+|----------------|-------------------------------------------------|
+| Problem report | Problem report updated with cause and procedure |
+
+### 3. Implementation and Verification
+
+The change is implemented. If the change includes a change to an existing product, it is handled according to
+SOP Change Management.
+
+After the change has been implemented, the problem report is reviewed whether it has been successfully fixed
+and can be closed. Closing the problem report is equivalent to successful verification.
+
+| Participants                                 |
+|----------------------------------------------|
+| Head of product development                  |
+| Person responsible for regulatory compliance |
+
+| Input              | Output                         |
+|--------------------|--------------------------------|
+| Problem report     | Resolved/closed problem report |
+| Implemented change |                                |
diff --git a/openregulatory/templates/techdoc/62304/soup-list.md b/openregulatory/templates/techdoc/62304/soup-list.md
new file mode 100644
index 00000000..80ea376d
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/soup-list.md
@@ -0,0 +1,47 @@
+# SOUP List (Software of Unknown Provenance)
+
+> The 62304 requires you to document your SOUP, which is short for Software of Unknown Provenance. In human
+> language, those are the third-party libraries you're using in your code, typically in your
+> `requirements.txt` or `Gemfile`.
+
+| Classes | IEC 62304:2006 Section                          | Document Section |
+|---------|-------------------------------------------------|------------------|
+| B, C    | 5.3.3 (Functional and Performance Requirements) | 2                |
+| B, C    | 5.3.4 (Hardware and Software Requirements)      | 2                |
+| B, C    | 7.1.2 (Hazardous Situations)                    | 2                |
+| B, C    | 7.1.3 (SOUP Anomaly Lists)                      | 2                |
+| A, B, C | 8.1.2 (Identify SOUP)                           | 2                |
+
+## 1 Risk Level Definitions
+
+> The 62304 requires you to assess risks associated with SOUP. The simplest way to do this is to classify each
+> SOUP as a certain risk level. Unless you're developing software which shoots radiation at patients, it's
+> likely that your SOUP risk levels remain "low" or "medium".
+
+| Risk Level | Definition                                                 |
+|------------|------------------------------------------------------------|
+| Low        | Malfunction in SOUP can't lead to patient harm.            |
+| Medium     | Malfunction in SOUP can lead to reversible patient harm.   |
+| High       | Malfunction in SOUP can lead to irreversible patient harm. |
+
+## 2 SOUP List
+
+> This is the actual SOUP list. For each third-party library you use, add an entry in the table below. The
+> idea is to only have one "global" SOUP list for your medical device even though the code may actually live
+> in multiple repositories. That's what the "software system" column is for; you could also mention your (git)
+> repository there.
+
+> When specifying requirements, the 62304 requires you to mention functional, performance, hard- and software
+> requirements. However, you may not have to re-state certain requirements if they apply to all SOUP,
+> e.g., "runs on Linux". So prefer to keep the requirements simple, in a way in which you would communicate them
+> to colleagues on your development team when answering the question "why did we import this library?".
+
+> As with all templates: It's more about the content (i.e., the columns you see below) than the tool (filling
+> this out in Google sheets / markdown / wherever). Nobody says that you have to maintain this as a Google
+> sheet. If you can find a way to integrate this in your workflow in a better way, e.g., in a markdown file in
+> your git repository, go for it! Just keep in mind that you need to be able to export it to send it to
+> auditors.
+
+| ID | Software System | Package Name | Programming Language | Version | Website                                          | Last verified at | Risk Level | Requirements               | Verification Reasoning                                                    |
+|----|-----------------|--------------|----------------------|---------|--------------------------------------------------|------------------|------------|----------------------------|---------------------------------------------------------------------------|
+| 1  | Mobile App      | react-native | JavaScript           | 0.61    | [Link](https://facebook.github.io/react-native/) | 23.10.2020       | Low        | * Runs JS on Android / iOS | Commonly used, maintained by a large organisation, sufficient test coverage |
diff --git a/openregulatory/templates/techdoc/62304/user-needs-list.md b/openregulatory/templates/techdoc/62304/user-needs-list.md
new file mode 100644
index 00000000..1143088e
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/user-needs-list.md
@@ -0,0 +1,39 @@
+# User Needs List
+
+> This is a list of your user needs (also referred to as "stakeholder requirements"). This is what you would
+> most commonly start with for your requirements mapping: it is the most high-level part of your design
+> input. Describe the generic requirements your device will need to meet. Only in a next step, these user
+> needs will be translated into (and linked to) software requirements which will present the technical
+> specifications of your product.
+
+> Of course, you could also use your own tool like Jira or GitHub issues for this. Just ensure that the
+> content (i.e. the columns shown here) is roughly the same.
+
+## Mapping of Standard Requirements to Document Sections
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 7.2.1                  | (All)            |
+| 7.3.3                  | (All)            |
+
+| IEC 62366-1:2015 Section | Title                                                                              | Document Section |
+|--------------------------|------------------------------------------------------------------------------------|------------------|
+| 5.2                      | Identify user interface characteristics related to safety and potential use errors | 1                |
+| 5.6                      | Establish user interface specification                                             | 1                |
+
+## 1. User Needs
+
+> Your user needs should typically take into account:
+>
+> * Regulatory requirements
+> * Use requirements for product functionalities, safety and performance in order to fulfill its intended use.
+> * Requirements from risk management: include all hazard-related use scenarios that must be tested during
+>   usability tests (note the last column on the right for that).
+
+| User Need ID | User Group      | Requirement Description                                                                                                | Safety-Critical? |
+|----------------------------|------------------------|------------------------------------------------------------------------------------------------------------------------|------------------|
+| 1                          | User                   | The software returns a score predicting Covid contraction based on (...).                                              | Yes              |
+| 2                          | User                   | Users can read the instructions for use or contact support in case of questions.                                       | Yes              |
+| 3                          | Company                | The software can be integrated with most laboratory systems in the intended use environment.                           | No               |
+| 4                          | Regulatory authorities | The device is developed in compliance with applicable regulations, norms and standards (e.g. IVDR / MDR, GDPR, HIPAA). | No               |
+| 5                          | (...)                  | (...)                                                                                                                  | (...)            |
diff --git a/openregulatory/templates/techdoc/62366/62366-mapping.md b/openregulatory/templates/techdoc/62366/62366-mapping.md
new file mode 100644
index 00000000..a639b275
--- /dev/null
+++ b/openregulatory/templates/techdoc/62366/62366-mapping.md
@@ -0,0 +1,27 @@
+# IEC 62366-1:2015 Mapping of Requirements to Documents
+
+This table maps all requirements of the IEC 62366-1:2015 (by section) to the relevant documents.
+
+> Note that the document names in the "Fulfilled in Document" column are based on the OpenRegulatory
+> templates. You'll probably have a different system for assigning document names, so feel free to rename
+> them.
+
+| Section | Title                                                                              | Fulfilled in Document                |
+|---------|------------------------------------------------------------------------------------|--------------------------------------|
+| 4.1.1   | Usability Engineering Process                                                      | SOP Integrated Software Development  |
+| 4.1.2   | Risk Control as it relates to User Interface design                                | Risk Table                           |
+| 4.1.3   | Information for Safety as it relates to Usability                                  | Usability Evaluation Report          |
+| 4.2     | Usability Engineering File                                                         | Usability Evaluation Plan, Report    |
+| 4.3     | Tailoring of the Usability Engineering effort                                      | Usability Evaluation Plan            |
+| 5.1     | Prepare Use Specification                                                          | SOP Integrated Software Development  |
+| 5.2     | Identify User Interface characteristics related to Safety and potential Use Errors | Software Requirements List           |
+| 5.3     | Identify known or foreseeable Hazards and Hazardous Situations                     | Risk Table                           |
+| 5.4     | Identify and describe Hazard-Related Use Scenarios                                 | List of Hazard-Related Use Scenarios |
+| 5.5     | Select the Hazard-Related Use Scenarios for Summative Evaluation                   | List of Hazard-Related Use Scenarios |
+| 5.6     | Establish User Interface Specification                                             | Software Requirements List           |
+| 5.7.1   | Establish User Interface Evaluation Plan / General                                 | Usability Evaluation Plan            |
+| 5.7.2   | Formative Evaluation planning                                                      | Usability Evaluation Plan            |
+| 5.7.3   | Summative Evaluation planning                                                      | Usability Evaluation Plan            |
+| 5.8     | Perform User Interface design, implementation and Formative Evaluation             | SOP Integrated Software Development  |
+| 5.9     | Perform Summative Evaluation of the Usability of the User Interface                | Usability Evaluation Protocol        |
+| 5.10    | User Interface of Unknown Provenance                                               | (not applicable)                     |
diff --git a/openregulatory/templates/techdoc/62366/list-of-hazard-related-use-scenarios.md b/openregulatory/templates/techdoc/62366/list-of-hazard-related-use-scenarios.md
new file mode 100644
index 00000000..24122d5d
--- /dev/null
+++ b/openregulatory/templates/techdoc/62366/list-of-hazard-related-use-scenarios.md
@@ -0,0 +1,27 @@
+# List of Hazard-Related Use Scenarios
+
+## Mapping of Standard Requirements to Document Sections
+
+| IEC 62366-1:2015 Section | Title                                                            | Document Section |
+|--------------------------|------------------------------------------------------------------|------------------|
+| 5.4                      | Identify and describe Hazard-Related Use Scenarios               | 1                |
+| 5.5                      | Select the Hazard-Related Use Scenarios for Summative Evaluation | 1                |
+
+## Summary
+
+The goal of the list of Hazard-Related Use Scenarios is to gather all Use Scenarios which could be associated
+with a Hazard, e.g., if a user doesn't understand a certain feature of the app (bad design leading to poor
+usability), then a Hazard could be encountered which could subsequently lead to a Hazardous Situation.
+
+## 1. Hazard-Related Use Scenarios
+
+> Fill out this list with Use Scenarios which could be Hazard-related. A good rule of thumb is to have 3-10
+> scenarios, based on the risk profile of your software.
+>
+> Also, note that you should prefer to create a spreadsheet for this table (e.g., in Google Sheets) as putting a
+> table in a document will surely lead to chaos. But then again, there's always a certain level of chaos in
+> regulatory documentation.
+
+| ID | User Group | Description        | App State / Environment                               | Tasks                                                         | Acceptance Criteria                 |
+|----|------------|--------------------|-------------------------------------------------------|---------------------------------------------------------------|-------------------------------------|
+| 1  | Physician  | Assess COVID score | 1) App is installed<br>2) App displays patient result | Understand COVID score and initiate further medical treatment | COVID score is understood correctly |
diff --git a/openregulatory/templates/techdoc/62366/usability-evaluation-plan.md b/openregulatory/templates/techdoc/62366/usability-evaluation-plan.md
new file mode 100644
index 00000000..f678c442
--- /dev/null
+++ b/openregulatory/templates/techdoc/62366/usability-evaluation-plan.md
@@ -0,0 +1,95 @@
+# Usability Evaluation Plan
+
+The Usability Evaluation Plan describes the Usability Evaluation activities and their required resources which
+will be performed for the device.
+
+## Mapping of Standard Requirements to Document Sections
+
+| IEC 62366-1:2015 Section | Title                                         | Document Section |
+|--------------------------|-----------------------------------------------|------------------|
+| 4.2                      | Usability Engineering File                    | (all)            |
+| 4.3                      | Tailoring of the Usability Engineering effort | (all)            |
+
+## 1. Relevant Processes
+
+Usability Engineering and Evaluation activities are defined in the **SOP Integrated Software Development**.
+
+## 2. Related Documents
+
+ * List of Hazard-Related Use Scenarios
+ * Usability Evaluation Report
+
+## 3. Roles
+
+| Title                                           | Name(s) |
+|-------------------------------------------------|---------|
+| Head of Usability                               |         |
+| Context / Subject Matter Expert, e.g., physician |         |
+
+## 4. Formative Usability Evaluation
+
+### 4.1 Methods
+
+Formative Usability Evaluation is performed with the following methods:
+
+ * **Presentation of mockups or prototypes to subject matter experts:** E.g., by demonstrating the
+   functionality in an in-person or remote screen sharing session.
+ * **Feedback sessions with UX/UI experts:** Showing concepts, designs, mockups or prototypes to internal or
+   external UX/UI experts with the goal of gathering feedback on potential usability problems and
+   improvements.
+ * **User Tests:** Letting users of the intended target user group use the device based on a Usability
+   Evaluation protocol, observing them and documenting potential Usability problems. This is essentially the
+   same methods as the Summative Usability Evaluation, with the only difference being that it's being done on a
+   development (non-final, non-release) version of the device with the goal of gathering knowledge for
+   improving the final device.
+
+### 4.2 Planning (Overview)
+
+| Date       | Description                                                                               |
+|------------|-------------------------------------------------------------------------------------------|
+| 01.01.2021 | *Formative Evaluation 1*<br>(Description of methods incl. environment, participants etc.) |
+
+## 5 Summative Usability Evaluation
+
+### 5.1 Method
+
+Summative Usability Evaluation is conducted by performing User Tests.
+
+User Tests must comply with the following requirements:
+
+ * The user profile is the one specified in the Device Description.
+ * All Hazard-Related Use Scenarios must be covered by test cases (see IEC 62366, para. 5.7.3 / 5.9).
+ * Sufficient stakeholder requirements / user needs must be covered by test cases to ensure that the product meets its intended use (see ISO 13485, para. 7.3.7)
+ * At least five test participants.
+ * The Usability Test Protocol must be filled out which descriptions of each use scenario and
+   instructions. It is also used to document the observations and discovered hazards.
+
+The following requirements are optional:
+
+ * Usability Tests are recorded, e.g., video/audio (either in-person or remotely) and screen recording (of
+   phone / desktop computer)
+
+Results of Summative Usability Evaluation are summarized in the Usability Evaluation Report, most importantly:
+
+ * Could all tasks in the Usability Test Protocol be achieved?
+   * If not, why?
+ * Which Use Errors occurred and could they lead to Hazardous Situations? --> Risk analysis of use errors
+
+## 5.2 Planning (Setting)
+
+#### Participants
+
+#### Setting
+
+#### Methods and Analysis
+
+> Describe whether it's done in person or remotely and how you will document the results (have a protocol at
+> the minimum), optionally also record the sessions.
+>
+> Also, describe how you plan to analyse the data.
+
+## 5.3 Planning (Overview)
+
+| Date       | Description                                                                               |
+|------------|-------------------------------------------------------------------------------------------|
+| 02.01.2021 | *Summative Evaluation 1*<br>(Description of methods incl. environment, participants etc.) |
diff --git a/openregulatory/templates/techdoc/62366/usability-evaluation-protocol.md b/openregulatory/templates/techdoc/62366/usability-evaluation-protocol.md
new file mode 100644
index 00000000..836328ac
--- /dev/null
+++ b/openregulatory/templates/techdoc/62366/usability-evaluation-protocol.md
@@ -0,0 +1,56 @@
+# Usability Evaluation Protocol
+
+## Mapping of Standard Requirements to Document Sections
+
+| IEC 62366-1:2015 Section | Title                                         | Document Section |
+|--------------------------|-----------------------------------------------|------------------|
+| 4.2                      | Usability Engineering File                    | (all)            |
+| 4.3                      | Tailoring of the Usability Engineering effort | (all)            |
+
+## 1. User Group and Environment
+
+> Describe the user group here, e.g., physicians with experience in a certain field.
+
+> Also, describe the environment in which the user test is being conducted. Obviously, both the user group and
+> environment should match whatever you described in your Intended Use. So, if your app is intended to be used
+> by emergency physicians in a brightly-lit hospital environment, you should also have these people do the
+> usability test in a similar environment.
+
+## 2. Preparation
+
+> Describe whether you prepare users in any way. Again, this should be based on the use context in which your
+> users will be using your device in real life. So, if people typically carefully read the user manual before
+> (not sure in which parallel universe that happens), you can give them the manual and some time to study
+> it. More realistically, you'll probably test how users handle your device when they haven't read the manual.
+
+> If there are official training which are required before users can use your device, you should do this
+> training first, of course.
+
+## 3. List of Tasks
+
+> This table lists the tasks you want your users to perform. It's kind of the master table which will be
+> copy-pasted for each user below - you'll be filling out the observations and hazards encountered by each
+> user.
+
+> As always, using a spreadsheet (e.g., Google Sheets) instead of a document is a very good idea here.
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+## 4. Protocols
+
+> Copy-paste the table above for each user and fill it out during the test. Note down the names and ages (or
+> any other important characteristics) per user.
+
+### User 1 (Name, Age)
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+### User 2 (Name, Age)
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
diff --git a/openregulatory/templates/techdoc/62366/usability-evaluation-report.md b/openregulatory/templates/techdoc/62366/usability-evaluation-report.md
new file mode 100644
index 00000000..715cc9e3
--- /dev/null
+++ b/openregulatory/templates/techdoc/62366/usability-evaluation-report.md
@@ -0,0 +1,62 @@
+# Usability Evaluation Report
+
+The Usability Evaluation report describes the results of all (formative and summative) Usability Evaluations.
+
+## Mapping of Standard Requirements to Document Sections
+
+| IEC 62366-1:2015 Section | Title                                             | Document Section |
+|--------------------------|---------------------------------------------------|------------------|
+| 4.1.3                    | Information for Safety as it relates to Usability | 5.4              |
+| 4.2                      | Usability Engineering File                        | (all)            |
+
+## 1. Relevant Processes
+
+Usability Engineering and Evaluation activities are defined in the **SOP Integrated Software Development**.
+
+## 2. Related Documents
+
+ * List of Hazard-Related Use Scenarios
+ * Usability Evaluation Report
+
+## 3. Summary of Formative Evaluations
+
+### 3.1 Formative Evaluation 1
+
+## 4. Summary of Summative Evaluation
+
+## 4.1 Methods
+
+> Copy-paste this section from the Usability Evaluation Plan (5.2 Planning (Setting)).
+
+### 4.2 Overview over Tests
+
+> Copy-paste this table from the Usability Evaluation Protocol.
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+### 5.2 Pass / Fail Counts of Tests
+
+> Count the pass/fail results from the Usability Evaluation Protocol
+
+| Test ID | Description | Total Count | Pass Count | Fail Count |
+|---------|-------------|-------------|------------|------------|
+|         |             |             |            |            |
+
+### 5.3 Use Errors and Hazards
+
+| Test ID | Description | Use Error | Potential Hazard |
+|---------|-------------|-----------|------------------|
+|         |             |           |                  |
+
+### 5.4 Information for Safety
+
+> Describe whether information for safety could correctly be perceived and understood by the users and
+> whether it supported the correct use of the medical device.
+
+### 5.5 Other Findings
+
+## 6. Qualitative Participant Feedback
+
+## 7. Conclusion
diff --git a/openregulatory/templates/techdoc/document-roadmap.md b/openregulatory/templates/techdoc/document-roadmap.md
new file mode 100644
index 00000000..d7008b6e
--- /dev/null
+++ b/openregulatory/templates/techdoc/document-roadmap.md
@@ -0,0 +1,66 @@
+# Document Roadmap TechDoc
+
+This is a proposed roadmap to creating the TechDoc file. The documents are grouped by "Design Phase". To each
+document, a responsible person is assigned as the author. Go through the list phase by phase. You can mix up
+the order of documents within a phase, but I recommend to finalize documents from one phase before moving on
+to the next.
+
+### PHASE 1: Planning & Feasability
+
+| Document                                        | Author                        | Comment                                                                                                                                                                            |
+|-------------------------------------------------|-------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Intended Use                                    | CEO                           | This is the most important document of your TechDoc. Business and Regulatory Strategy depend on it.                                                                                |
+| Medical Device Classification                   | QA/RA Manger                  | Defining the product's medical device classification acc. to MDR.                                                                                                                  |
+| Product Roadmap                                 | Product Manager               | Not an essential document. This is for feasibility assessments and resource planning. Helps to keep track of what's to come.                                                       |
+| Software Development and Maintenance Plan       | Software Developer            | Giving product-specific information on the tools, resources and methods to be used for software development. Helpful for developer teams to align regarding the development setup. |
+| Change Evaluation List                          | QA/RA Manger                  | Listing and assessing gaps between the last and the upcoming software version. Follows criteria from MDCG 2020-3. Not needed for the very first release.                           |
+| Risk Management Plan and Risk Acceptance Matrix | Risk Manager                  | Specifies the methods for assessing risks to be used for the product at hand. Defines probability and severity categories and acceptable ranges.                                   |
+| Clinical Evaluation Plan                        | Clinician / Scientific Person | Specifying the methodology that shall be used to assess the clinical benefits and risks of the product.                                                                            |
+
+### PHASE 2: Specification
+
+| Document                             | Author                               | Comment                                                                                                    |
+|--------------------------------------|--------------------------------------|------------------------------------------------------------------------------------------------------------|
+| User Needs List                      | Product Manager                      | This is a list of high-level requirements. Most of them will be implemented through Software Requirements. |
+| User Needs Checklist                 | QA/RA Manager                        | Checking if the User Needs List makes sense.                                                               |
+| Software Requirements List           | Developer-adjacent person            | Specifying how User Needs will be incorporated in the software. Describing the details of a feature.       |
+| List of Hazard-Related Use Scenarios | Risk Manager                         | Identifying scenarios in which users could be prone to hazards.                                            |
+| Risk Table                           | Risk Manager                         | Anticipating and assessing risks. Gathering input from various channels.                                   |
+| Software Requirements Checklist      | QA/RA Manager                        | Checking if the Software Requirements List makes sense.                                                    |
+| Software Test Plan                   | Software Developer                   | Defining tests for every Software Requirement and mapping them to each other.                              |
+| Usability Test Plan                  | Product Manager / Usability Engineer | Specifying the methodologies to be used to conduct the Usability Test.                                     |
+
+### PHASE 3: Development
+
+| Document              | Author             | Comment                                                                                                         |
+|-----------------------|--------------------|-----------------------------------------------------------------------------------------------------------------|
+| SOUP List             | Software Developer | List of external libraries, frameworks and packages used in the product, incl. their assessment of criticality. |
+| Software Architecture | Software Developer | Description/Graphic outlining the software components and their interaction.                                    |
+
+The actual programming work takes place in this phase. It makes sense to create the SOUP list and the software
+architecture immediately before programming begins and to adjust them if anything changes during code
+creation. These documents should actually be created in advance, but due to the iterative nature of software
+development, it will not be possible to plan everything before the actual work begins. Therefore, it makes
+sense to create them in parallel with the programming.
+
+### PHASE 4: Verification and Validation
+
+| Document                   | Author                               | Comment                                                                                                                                                                           |
+|----------------------------|--------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Software Test Results      | QA Tester                            | Results of the Software Tests: passed or failed?                                                                                                                                  |
+| List of Known Anomalies    | Software Developer / Product Manager | List of known bugs and failed software tests. Justification why the software can still be released without impacting benefit/safety and a timeline when those bugs will be fixed. |
+| Instructions For Use       | Person with the best overview        | The name says it all.                                                                                                                                                             |
+| Usability Test Protocol    | Product Manager / Usability Engineer | Specifying the actual usability test cases: Testing User Needs, Hazard-Related Use Scenarios and Instructions for Use.                                                            |
+| Usability Test Report      | Product Manager                      | Summary of the results of the Usability Test.                                                                                                                                     |
+| Clinical Evaluation Report | Clinician / Scientific Person        | Analysing scientific data to prove the products safety and efficacy.                                                                                                              |
+| Risk Management Report     | Risk Manager                         | Summary of the Risk Management Activities                                                                                                                                         |
+
+### PHASE 5: Product Release
+
+| Document                   | Author                                | Comment                                                                                                                                                             |
+|----------------------------|---------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| GSPR List                  | QA/RA Manager                         | Checking if the "General Safety and Performance Requirements" are fulfilled.                                                                                        |
+| PMS (/PMCF) Plan           | QA/RA Manager                         | Planning the product-specific activities for Post-Market Surveillance. If the clinical data is not sufficient, also plan Post-Market Clinical Follow-Up activities. |
+| Software Release Checklist | QA/RA Manager                         | Checking if all the requirements are fulfilled, if the documents are complete and if the product is safe to be used.                                                |
+| Release Notes              | Product Manager OR Software Developer | Description of new features in the current release.                                                                                                                 |
+| Declaration of Conformity  | QA/RA and CEO                         | Declaring the product's conformity with the regulations and standards.                                                                                              |
diff --git a/openregulatory/templates/techdoc/list-of-known-anomalies.md b/openregulatory/templates/techdoc/list-of-known-anomalies.md
new file mode 100644
index 00000000..ace1cfb5
--- /dev/null
+++ b/openregulatory/templates/techdoc/list-of-known-anomalies.md
@@ -0,0 +1,16 @@
+# List of Known Anomalies
+
+> This template is supposed to give you an idea of the structure. Don't use Microsoft Word - this is thought
+> as an excel / sheets file.
+
+This list shows technical errors ("bugs") of the current device which were decided not to be corrected before the
+release of the latest version.
+
+It, therefore, serves as an overview and as a documentation of reasoning for non-correction.
+
+## Anomalies
+
+| Title            | Description                                                                                                                                                          | Impact / Hazard                                                                                                                                    | Discovery (Date, How, By Whom)                         | Proposed Correction                | Justification for Delay                                                                                         | Timeline             |
+|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|------------------------------------|-----------------------------------------------------------------------------------------------------------------|----------------------|
+| Default language | If the app is installed on a smartphone with unsupported language, the default language is German. Users then have to navigate to the language settings for changes. | Users in countries with unsupported language are likely not German-speaking and may not be able to use the app without changing language settings. | 2022-04-01 during usability testing by Product Manager | Change default language to English | Per appstore setting, the app is currently only available in countries whose predominant language is supported. | Next version release |
+| (...)            | (...)                                                                                                                                                                | (...)                                                                                                                                              | (...)                                                  | (...)                              | (...)                                                                                                           | (...)                |


Test patch:
diff --git a/openregulatory/templates/techdoc/62304/software-system-test-plan.md b/openregulatory/templates/techdoc/62304/software-system-test-plan.md
new file mode 100644
index 00000000..39156d5d
--- /dev/null
+++ b/openregulatory/templates/techdoc/62304/software-system-test-plan.md
@@ -0,0 +1,16 @@
+# Software System Test Plan
+
+> `SR ID` refers to the ID of the software requirement which is tested by this test.
+
+> Note that this is, strictly speaking, not a "plan" because it already includes the results (columns "Actual"
+> and "Pass?"). To keep things clean, I'd suggest splitting this table up into a "plan" and a "protocol"
+> (suggestion by a friendly auditor). The plan contains all columns below except "Actual" and
+> "Pass?". The protocol contains all columns. The idea is this: It makes sense to write the plan before
+> actually doing the testing. You don't want to be changing the test steps when you notice your tests are
+> failing (surely nobody would do that). So you write the plan first, finalize it, then copy-paste it to a
+> protocol in which you enter the results after you've done your tests.
+
+| ID | SR ID | Description                                    | Steps                                                                          | Expected                              | Actual                      | Pass? |
+|----|-------|------------------------------------------------|--------------------------------------------------------------------------------|---------------------------------------|-----------------------------|-------|
+| 1  | 1     | Login with correct email and password succeeds | 1. Enter email steve@apple.com<br>2. Enter password atari<br>3. Click login    | Redirect to account page              | Redirect to account page    | Pass  |
+| 2  | 1     | Login with incorrect email and password fails  | 1. Enter email jony@apple.com<br>2. Enter password butterfly<br>3. Click login | Error "invalid credentials" displayed | Error "invalid credentials" | Pass  |