@neobiotechlabs/neobiotech-dev-agent 0.1.7

package/vendor/dev-docs-templates/templates/mdr_docs/CA/mdr-declaration-of-conformity.md

@@ -0,0 +1,75 @@
+# 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: \<enter class\>**
+
+Classification based on \<enter MDR reference, for example: Annex VIII, Chapter 3, Paragraph 6, Rule 11 (for
+software devices)\>.
+
+> For context, read Art. 51 MDR, Section 1. You can find the classification rule applicable to your
+> medical device set out in Annexes VIII of the MDR.
+>
+> For example: software intended to provide information used to take decisions with diagnosis or therapeutic
+> purposes and software intended to monitor physiological processes is classified as class IIa according to
+> rule 11 of the Annex.
+
+## Conformity Assessment
+
+Conformity assessment procedure: *\<enter reference to applicable Annex, for example for class I: Annex II and
+III\>* of the Regulation (EU) 2017/745.
+
+> For context, read Art. 52 MDR, Section 2. You can find the conformity assessment procedures
+> applicable to your medical device class set out in Annexes IX to XI of the MDR:
+>
+> * For class III devices (other than custom-made or investigational devices) -> Annex IX. Alternatively:
+>   Annex X + XI
+> * For class IIb devices (other than custom-made or investigational devices) -> Chapters I and III of Annex
+>   IX, incl. TechDoc assessment according to Para. 4 of Annex IX for at least one representative device of a
+>   generic device group. For class IIb implant devices, Annex IX applies to every device. Alternatively,
+>   manufacturers may choose type examination following Annex X in combination with Annex XI.
+> * For class IIa devices (other than custom-made or investigational devices) -> Chapters I and III of Annex
+>   IX, incl. TechDoc assessment according to Para. 4 of Annex IX for at least one representative device for
+>   each category of devices.
+> * For class I devices (other than custom-made or investigational devices) -> draw up technical documentation
+>   according to Annexes II and III.
+> * For class I devices in sterile condition, including a measuring function or constituting reusable surgical
+>   instruments -> apply the procedures set out in Chapters I and III of Annex IX, or in Part A of Annex XI.
+
+The Medical Device referenced above meets the provisions of Regulation (EU) 2017/45 on medical devices.
+
+> Note #1: 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.
+>
+> Note #2: read Annex IV MDR to double-check if all relevant information is included! For example, if
+> applicable, include product / trade name, Notified Body information, etc.
+
+---
+
+Place, Date, Signature of CEO
+
+---
+
+Place, Date, Signature of PRRC
+
+---
+
+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.

package/vendor/dev-docs-templates/templates/mdr_docs/CA/post-market-clinical-follow-up-plan.md

@@ -0,0 +1,162 @@
+# Post-Market Clinical Follow-Up Plan (PMCFP)
+
+This document is used to plan all post-market clinical follow-up activities for the \<name of the medical
+device].
+
+## Product information
+
+| Parameter              | Description |
+|------------------------|-------------|
+| Product or trade name: |             |
+| Model and type:        |             |
+| Intended purpose:      |             |
+
+## Context
+
+> Check out this guidance document which may further help you to fill out the template: MDCG 2020-7
+> Post-market clinical follow-up (PMCF) Plan Template: A guide for manufacturers and notified bodies
+
+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.
+
+## 1. Activities related to PMCF: general and specific methods and procedures
+
+> This section outlines post-market activities for PMCF, detailing general and specific methods/procedures
+> related to the product's scope. It also covers the purpose of each activity, the rationale behind chosen
+> methods, and anticipated limitations. Activity timelines are to be defined quarterly or yearly.
+>
+> Examples of PMCF activities include:
+>
+> 1. **Manufacturer Device Registry:** Specific to the device type or medical device group, include a brief
+>    plan description, specifying quality and quantity data based on device risk.
+> 2. **PMCF Studies:** Details study plans, encompassing design, sample size, endpoints, and
+>    inclusion/exclusion criteria.
+> 3. **Surveys:** Describes planned surveys for collecting information on the use of the medical device.
+>
+> The overarching aim is to streamline post-market activities, ensuring comprehensive data collection,
+> analysis, and validation.
+
+### 1.1 General methods and procedures
+
+> According to the MDR, Annex XIV, 6.2 The PMCF plan shall include at least:
+>
+> (a) the general methods and procedures of the PMCF to be applied, such as gathering of clinical experience
+> gained, feedback from users, screening of scientific literature and of other sources of clinical data;
+>
+> Below are two examples provided:
+
+| Method 1                                         | \<Literature Review\>                                                                                                                                            |
+|--------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description:                                     | \<Literature search as defined in the search protocol of the CER\>                                                                                               |
+| Search period:                                   | \<Beginning from last update of CER until Month/Year\>                                                                                                           |
+| Objective:                                       | \<Confirming the findings of the initial Clinical Evaluation Report and identifying new potential benefits and risks\>                                           |
+| Search Strategy:                                 | \<Copy paste your search strategy from the CER here\>                                                                                                            |
+| Rationale and known limitations of the activity: | \<Address device risk, the novelty of the product and/or of the clinical procedure, the sufficiency of clinical data in the CER & the objective of this method\> |
+
+| Method 2                                         | \<Feedback from users or patients\>                                                                                                                              |
+|--------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description:                                     | \<Describe the survey\>                                                                                                                                          |
+| Search period:                                   | \<State the survey periode here\>                                                                                                                                |
+| Objective:                                       | \<Describe the objective of your survey\>                                                                                                                        |
+| Additional information                           | \<Countries, sponsor, survey sides...\>                                                                                                                          |
+| Rationale and known limitations of the activity: | \<Address device risk, the novelty of the product and/or of the clinical procedure, the sufficiency of clinical data in the CER & the objective of this method\> |
+
+### 1.2 Specific methods and procedures
+
+> According to the MDR, Annex XIV, 6.2 The PMCF plan shall include at least:
+> (b) the specific methods and procedures of PMCF to be applied, such as evaluation of suitable registers or PMCF studies;
+
+| Method 3                                         | \<PMCF Study\>                                                                                                                                                   |
+|--------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description:                                     | \<Describe the study\>                                                                                                                                           |
+| Search period:                                   | \<State the study periode here\>                                                                                                                                 |
+| Objective:                                       | \<Describe the objective of your study\>                                                                                                                         |
+| Additional information                           | \<Countries, sponsor, survey sides...\>                                                                                                                          |
+| Rationale and known limitations of the activity: | \<Address device risk, the novelty of the product and/or of the clinical procedure, the sufficiency of clinical data in the CER & the objective of this method\> |
+
+| Method 4                                         | \<Device registry\>                                                                                                                                              |
+|--------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description:                                     | \<Database search as defined in the CER\>                                                                                                                        |
+| Search period:                                   | \<Beginning from last update of CER until Month/Year\>                                                                                                           |
+| Objective:                                       | \<Confirming the findings of the initial Clinical Evaluation Report and identifying new potential benefits and risks\>                                           |
+| Search Strategy:                                 | \<Copy paste your search strategy from the CER here\>                                                                                                            |
+| Rationale and known limitations of the activity: | \<Address device risk, the novelty of the product and/or of the clinical procedure, the sufficiency of clinical data in the CER & the objective of this method\> |
+
+## 2. Reference to the relevant parts of the technical documentation
+
+> In this segment, the manufacturer must incorporate citations to pertinent details from both the clinical
+> evaluation report and the risk management file. These references are subject to analysis, follow-up, and
+> assessment within this plan. Alternatively, the manufacturer must explicitly declare if there is no relevant
+> information from the clinical evaluation report and/or the risk management file that requires consideration
+> in this plan.
+
+### 2.1 Clinical Evaluation Report (date and **version)**
+
+###### Relevant information to be further analysed and monitored:
+
+* \<Describe what needs to be analysed\>
+
+> Example: The clinical data gathered and evaluated as a result of this PMCF plan will be used to update and
+> verify the chapters 11.6 (literature summary and conclusion), 12 (clinical experience data), 13
+> (risk-benefit assessment) and the conclusion of the CER. The literature will furthermore be searched for
+> similar devices with a focus on associated risks and the state of the art.
+
+* No relevant information from the clinical evaluation report to be considered in this plan
+
+### 2.2 Risk Management File (date and version)
+
+###### Relevant information to be further analysed and monitored:
+
+* \<Describe what needs to be analysed\>
+
+> Example: Clinical data will be used to ensure the ongoing appropriateness of identified hazards, hazardous
+> situations, harms, their frequency and severity estimations in the risk assessment & risk
+> control. Furthermore, the data including information on similar devices shall be evaluated to identify
+> potential emerging risks in the risk assessment & risk control.
+
+* No relevant information from the risk management file to be considered in this plan
+
+## 3. Evaluation of clinical data relating to equivalent or similar devices
+
+> In this section, the manufacturer is required to compile information on equivalent or similar devices, the
+> clinical data of which will be subsequently assessed and presented in the PMCF report. It is important to
+> highlight that PMCF data, aimed at demonstrating ongoing safety and performance, should primarily originate
+> from the specific device under evaluation. While data from equivalent or similar devices may be utilized—for
+> instance, to update information on the state of the art or to identify and further evaluate relevant safety
+> outcomes—the selected devices must remain consistent throughout the technical documentation. It is essential
+> to specify whether the chosen device is confirmed to be equivalent or is categorized as a similar
+> device. Each listed device should include a clear reference to the relevant sections of the Clinical
+> Evaluation Report (CER).
+
+The following equivalent or similar devices have been chosen and the clinical data will subsequently assessed:
+
+| Parameter                                                                                 | Equivalent / similar device 1 | Equivalent / similar device 2 |
+|-------------------------------------------------------------------------------------------|-------------------------------|-------------------------------|
+| Product name of equivalent / similar device                                               |                               |                               |
+| Intended purpose                                                                          |                               |                               |
+| Intended users                                                                            |                               |                               |
+| Intended patient population                                                               |                               |                               |
+| Medical condition                                                                         |                               |                               |
+| Indication                                                                                |                               |                               |
+| Reference to clinical data evaluation in the CER (date, version and location in the text) |                               |                               |
+
+## 4. PMCF evaluation report
+
+The findings of the PMCF will be summarized in the PMCF Evaluation Report that is part of the clinical
+evaluation report and the technical documentation.
+
+---
+
+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.

package/vendor/dev-docs-templates/templates/mdr_docs/CA/post-market-surveillance-plan.md

@@ -0,0 +1,175 @@
+# 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 or the Periodic Safety Update Report.
+
+**Regulatory References:**
+
+|                              |                                  |
+|------------------------------|----------------------------------|
+| EU Regulation 2017/745 (MDR) | Art. 84 and Annex III, Para. 1.1 |
+
+## 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 characterization 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 | SOP Post-Market Surveillance                |
+| Effective and appropriate methods and processes to assess the collected data;                                                                                                                                                                                                             | SOP Post-Market Surveillance                |
+| 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;                                                                                                | PMS Plan - Trend Identification & Reporting |
+| Effective and appropriate methods and tools to investigate complaints and analyze market-related experience collected in the field;                                                                                                                                                       | SOP Feedback Management                     |
+| 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;     | PMS Plan - Trend Identification & Reporting |
+| Methods and protocols to communicate effectively with competent authorities, notified bodies, economic operators and users;                                                                                                                                                               | SOP Vigilance                               |
+| Reference to procedures to fulfill the manufacturers obligations laid down in Articles 83, 84 and 86;                                                                                                                                                                                     | SOP Post-Market Surveillance                |
+| Systematic procedures to identify and initiate appropriate measures including corrective actions;                                                                                                                                                                                         | SOP CAPA                                    |
+| Effective tools to trace and identify devices for which corrective actions might be necessary;                                                                                                                                                                                            | SOP Product Certification and Registration  |
+| A PMCF plan as referred to in Part B of Annex XIV, or a justification as to why a PMCF is not applicable.                                                                                                                                                                                 | SOP Clinical Evaluation                     |
+
+## 2. Data Collection Activities
+
+| PMS activity                                                                                                                                                                                                                | Responsibility               | When?      | Documented in                              |
+|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------|------------|--------------------------------------------|
+| Incident documentation and analysis of undesirable side effects                                                                                                                                                             | QMO                          | Annually   | PMS Report / PSUR                          |
+| Assess feedback (customer complaints, sales feedback)                                                                                                                                                                       | Head of Product              | Annually   | PMS Report / PSUR                          |
+| Check SOUP for new published issues                                                                                                                                                                                         | Head of Software Development | Biannually | PMS Report / PSUR                          |
+| Research data about similar products in the market                                                                                                                                                                          | QMO                          | Annually   | PMS Report / PSUR                          |
+| Conduct post-market clinical follow-up activities as planned                                                                                                                                                                | Head of Medical Team         | Annually   | PMCF Evaluation Report / CER               |
+| Research scientific publications                                                                                                                                                                                            | Head of Product              | Annually   | PMCF Evaluation Report / CER               |
+| Research updates of standards and legislation                                                                                                                                                                               | QMO                          | Annually   | PMS Report / PSUR                          |
+| Analyze trends, decide on necessary measures and implement them                                                                                                                                                             | QMO                          | Annually   | PMS Report / PSUR                          |
+| Update risk management file                                                                                                                                                                                                 | QMO                          | Annually   | Risk Management Report / PMS Report / PSUR |
+| Compile post-market clinical follow-up report                                                                                                                                                                               | Head of Medical Team         | Annually   | PMCF Evaluation Report / CER               |
+| Compile Periodic Safety Update Report                                                                                                                                                                                       | Head of Product              | Annually   | PMCF Evaluation Report / CER               |
+| Upload PSUR to Eudamed database                                                                                                                                                                                             | QMO                          | Annually   | N/A                                        |
+| Compile post-market surveillance plan and post-market clinical follow-up plan for next surveillance interval                                                                                                                | QMO                          | Annually   | PMS & PMCF Plan                            |
+| Volume of sales, an estimate evaluation of the size and other characteristics of the population (such as profession) using the device and, where practicable, the usage frequency of the device, volume of sales by country | QMO                          | Annually   | PMS Report / PSUR                          |
+
+## 3. Methods and Procedures
+
+> Include mandatory data sources in the PMS plan for each product, with additional methods based on risk class
+> and product type. Justify any non-applicability.
+
+### 3.1 Feedback
+
+### Serious Incidents and FSCA
+
+The insert report type, e.g. PMS Report or PSUR will summarize the number of reported serious incidents, their
+investigation results and any taken subsequent measures.
+
+### Non-serious Incidents and Expected Undesirable Side-Effects
+
+The PMS Report or PSUR will summarize the evaluation results and conclusions, including any taken preventive
+or corrective actions.
+
+### Proactively gathered Feedback
+
+Proactively collect feedback from distributors, users, and importers, including inputs not considered in
+previous sections. This encompasses feedback on usability, both positive and regarding issues, gathered
+through client visits, conferences, and events. General market feedback will also be actively obtained during
+client visits, conferences, fairs, and specified events. Specify objectives, acceptance criteria, and
+responsible persons for these activities. The aim is to identify new risks, verify existing ones, and assess
+benefits and use-related aspects of the medical device. Evaluate and summarize the gathered information. If
+potential serious incidents arise, follow the SOP Vigilance. The PMS Report or PSURwill summarize the results.
+
+### 3.2 Trend Identification and Reporting
+
+According to the MDR, Article 88 non-serious incidents and expected undesirable side-effects are subject to
+trend analysis. Statistically significant increases in the frequency or severity will be reported.  There are
+three types of changes that can be indicated by a trend analysis:
+
+* a sudden significant deviation like an outlier or spike, respectively;
+* significant trends, i.e. repetitive deviations or continuous drifting away from the history of earlier
+  values;
+* detection by visual inspection, whether the data are subject to cyclic effects, e.g. of calendar events like
+  summer holidays or end of budget periods.
+
+All incidents deemed non-serious and anticipated undesirable side-effects will undergo meticulous
+documentation and categorization, encompassing occurrences such as the arrival of a non-sterile device or a
+software crash. This process is crucial for maintaining a standardized approach, ensuring comparability across
+different incidents. To achieve this, normalization will be applied, factoring in the respective sales numbers
+or the number of installed devices per month.
+
+The data obtained will be graphically represented for each incident category, portraying the number of
+normalized incidents against the corresponding month. This visualization serves to illuminate the temporal
+progression of these incidents over time, facilitating a comprehensive understanding of trends and
+patterns. Adhering to the guidelines outlined in ISO/TR 20416 for Medical Devices - PMS for manufacturers,
+Rule 3 of the Nelson Rules will be employed to detect trends. A trend is detected, where six or more points in
+a row exhibit a continuous upward trajectory. In addition, long term trends are detected by visual inspection
+and review of the plotted incidents. If a trend is detected, a CAPA will be opened to investigate the
+incidents.
+
+### 3.3. Databases and Registers
+
+> Specify applicable literature databases, e.g. PubMed, Embase, COCHRANE, etc. for the gathering of clinical
+> data. If you have a separate PMCF plan which already contains the literature search as one of the planned
+> PMCF activities, you may provide a brief statement that there is a search strategy for literature in the
+> PMCF plan.
+
+### SOUP Incident Reports
+
+Check device SOUP list and research incident reports from last 12 months.
+
+### Technical, Specialist & Regulatory Information
+
+Applicable literature are product standards and guidelines as documented in the checklist of General Safety
+and Performance Requirements according to Annex I of Regulation (EU) 2017/745. These serve to determine the
+current state of the art and possible technical improvements and will be monitored on a yearly basis for
+changes and renewals. Furthermore, the Medical Device Coordination Group (MDCG) publications (guidance
+documents) will be reviewed with regards to guidance on interpretation of process- or product-relevant
+interpretations of regulatory requirements in the Regulation (EU) 2017/745. The < PMS Report or PSUR\> will
+summarize the results.
+
+### Other Publicly Available Information about Similar Medical Devices
+
+Identify the databases to be utilized for investigating incidents and recalls related to comparable devices
+(e.g., through MAUDE, BfArM, MHRA). Clearly outline the similar devices and establish appropriate search and
+evaluation criteria. A sample approach is provided below:
+
+| Database      | BfArM                                                    |
+|---------------|----------------------------------------------------------|
+| Criteria:     | Safety Information (Safety warnings, alerts and recalls) |
+| Timeframe:    | January 1 – December 31 2020                             |
+| Search terms: | E.g. Similar Device Name                                 |
+
+### 3.4. PMCF
+
+> If PMCF is exempt, add a justification.
+>
+> PMCF may only be exempt under one of the two following conditions:
+>
+> The demonstration of conformity with general safety and performance requirements based on clinical data is
+> not deemed appropriate, and adequate justification for the non-applicability of a clinical evaluation report
+> has been given; or It is a product without an intended medical purpose (see Annex XVI of Regulation (EU)
+> 2017/745).
+>
+> Otherwise:
+>
+> A PMCF plan has been developed for this device to consistently collect relevant clinical data, confirming
+> the benefit-risk determination in the Risk Management Report and Clinical Evaluation Report. This includes
+> assessing clinical safety, performance, any claims, and its alignment with the current state of the art. The
+> specific PMCF activities are contingent on factors such as device innovation, the availability of adequate
+> clinical data, inherent risks, and device type. These considerations have guided the planning of suitable
+> PMCF methods.
+
+## 4. Planned PMS Report/ Periodic Safety Update Report \(PSUR\)
+
+> Please state the month and year of the planned PMS report (for Class I devices)/ of the PSUR (for all other
+> devices).
+
+---
+
+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.

package/vendor/dev-docs-templates/templates/mdr_docs/CA/risk-management-cybersecurity-checklist.md

@@ -0,0 +1,67 @@
+# Questionnaire "Cybersecurity for Medical Devices - Technical Documentation"
+
+Version 1, dated 21st of March, 2023
+
+### 1. Preliminary remarks
+
+* This document was compiled by the [German Notified Bodies
+  Alliance](https://www.ig-nb.de/fileadmin/user_upload/ig-nb/Questionnaire_Cybersecurity_for_Medical_Devices_-_Technical_Documentation_-_Version_1.pdf)
+  ("Interessengemeinschaft der Benannten Stellen für Medizinprodukte in Deutschland", IG-NB) and is intended
+  to serve as orientation for Notified Bodies, manufacturers and interested parties. It makes no claim to
+  completeness or mandatory application.
+* This document covers assessments of Technical Documentation for MDR / IVDR. Not all requirements of MDR,
+  IVDR and MDCG 2019-16 are covered in this document.
+* Created by Jan Küfner (TÜV SÜD), Dr. Abtin Rad (TÜV SÜD), Dr. Andreas Schwab (TÜV Rheinland), Volker Sudmann
+  (mdc medical device certification), Markus Bianchi (DNV Medcert), Martin Tettke (Berlin Cert), Michael Bothe
+  (DQS Med), Mark Küller (TÜV-Verband / IG-NB). It replaces the previous version "IT Security for Medical
+  Devices“ (Version 5, 09.06.2022).
+* Questions regarding the security risks of artificial intelligence can be found in latest version of IG-NB's
+  "Questionnaire Artificial Intelligence (AI) in Medical Devices".
+* Compliance to IEC 81001-5-1 is not expected, however recommended, prior to the end of its transition
+  period. Compliance to IEC 81001-5-1 prior its transition period is however recommended. In the following
+  tables IEC 81001-5-1 is mentioned only for complementary purposes. Questions for manufacturers are solely
+  based on the current requirements (MDR, IVDR, MDCG 2019-16)
+* Since cybersecurity evolves on a regulatory and technological level, this document is intended to reflect
+  the current state of the art at the time of creation only.
+
+**References:**
+
+* Regulation (EU) 2017/745 (MDR), dated 5 April 2017
+* MDCG 2019-16 - Guidance on Cybersecurity for medical devices, Rev. 1, 2020-07
+* IEC 62304:2006-05 Medical device software - Software life cycle processes
+* IEC 81001-5-1:2021-12 Health software and health IT systems safety, effectiveness and security — Part 5-1:
+  Security — Activities in the product life cycle
+
+### 2. System Description
+
+| Item | Source | Requirement(s) | IG-NB Commentary | Manufacturer Reference for Compliance |
+| ---- | ------ | -------------- | ---------------- | ------------------------------------- |
+| 2.1 | State of the Art (SOTA) | An appropriate system diagram must be available. | Is an appropriate system diagram available? | Yes, see:<br>\- Software development plan<br>\- Software architecture |
+| 2.2 | IEC 81001-5-1 cl. 7.2 | 'All products have a threat model specific to the current development scope. Characteristics (where applicable): correct flow of categorized information throughout the system, trust boundaries, data stores, internal/external communication protocols etc.' | Note: a complete system diagram should include the following:<br>1\. All medical devices incl\. their interfaces \(e\.g\. bluetooth\, wifi\, ethernet\)\, utilized protocols \(e\.g\. HL7\, DICOM\, HTTPS\, MQTTS\, custom\) on those interfaces and their implemented technical specification \(e\.g\. implemented protocol version\) incl\. the type of data being transferred \(e\.g\. personal health information\, therapeutic commands\, updates\, remote access\) on those interfaces\.<br>2\. All human machine interfaces within the system \(e\.g\. screens\, keyboards\)\. | Potential cyber security risks and IT-security concerns have been taken into account within the framework of the existing FMEA risk analysis, following the ISO 14971 standard for risk management in medical devices. |
+
+### 3. Security Risk Management
+
+| Item | Source | Requirement(s) | IG-NB Commentary | Manufacturer Reference for Compliance |
+| ---- | ------ | -------------- | ---------------- | ------------------------------------- |
+| 3.1 | MDCG 2019-16 cpt. 3.2 | 'The security risk management process has the same elements as the safety risk management process, all documented in a security risk management plan. The process elements are security risk analysis, security risk evaluation, security risk control, evaluation of residual security risk and reporting.' | Is a security risk analysis available? | Yes, see:<br>\- Risk management plan<br>\- Risk table<br>\- Risk management report |
+| 3.2 | MDCG 2019-16 cpt. 3.4<br>and<br>IEC 81001-5-1 cl. 7.2 | 'Threat Modelling techniques are a systematic approach for analyzing the security of an item in a structural way such that vulnerabilities can be identified, enumerated and prioritized, all from a hypothetical attacker's point of view.'<br>AND<br>'(...) Employ activities to ensure that all products have a threat model specific to the current development scope.' | Does the security risk assessment contain an appropriate and systematic threat model?<br>Note: STRIDE is a systematic threat modelling technique, since it evaluates threat categories interface by interface. | Potential cyber security risks and IT-security concerns have been taken into account within the framework of the existing FMEA risk analysis, following the ISO 14971 standard for risk management in medical devices. |
+| 3.3 | MDCG 2019-16 cpt. 3.4 | 'Threat modelling typically employs a systematic approach to identify attack vectors and assets most desired by an attacker.'<br>AND<br>\- 'Establish activities which identify and document any vulnerabilities\, threats and associated adverse impacts affecting confidentiality\, integrity\, availability of assets\.<br>\- Consider intended use and the intended environment of use\.' | Is the threat model complete and correct (e.g. discussing all applicable threats for all relevant attack vectors)? | Yes, see risk table. |
+| 3.4 | IEC 81001-5-1 cl. 7.3 | \- Establish activities to estimate risk of vulnerabilities\.<br>\- Risk estimation should consider adverse impact of vulnerability to security<br>\- Estimation can be supported by using vulnerability scoring<br>\- Scoring system can be based on a likelihood/severity scheme used by the manufacturer for other risks<br>\- Evaluate estimated risks<br>\- Determine if risk is acceptable or not \(based on scoring\)<br>\- Inform product risk management process | Is the risk pre- and post-mitigation appropriately estimated?<br>Note 1: quantitative risk assessment is acceptable.<br>Note 2: security risk is a combination of exploitability and severity.<br>Note 3: alteration or disclosure of patient data can lead to harm. | Yes, see:<br>\- Risk table<br>\- Risk management report |
+| 3.5 | MDCG 2019-16 cpt. 3.2 | 'When a security risk or control measure could have a possible impact on safety and effectiveness, then it should be included in the safety risk assessment.' | Are security mitigations (if any) that might affect safety appropriately discussed? | Yes, see:<br>\- Risk table<br>\- Risk management report |
+| 3.6 | MDCG 2019-16 cpt. 3.3 | ‘Where there is an impact on safety or effectiveness, manufacturers shall select the most appropriate risk control solution, in the following order of priority:<br>a) Eliminate or reduce risks as far as possible through safe design and manufacture;<br>b) Where appropriate, take adequate protection measures, including alarms if necessary, in relation to risks that cannot be eliminated;<br>c) Provide information for safety (warnings/precautions/contra-indications) and, where appropriate, training to users.<br>For security, a similar approach can be taken:<br>a) Eliminate or reduce security risks as far as feasible through secure design and manufacture;<br>b) Where appropriate, take adequate protection measures, including security notifications if necessary, in relation to risks that cannot be eliminated;<br>c) Provide information for security (warnings/precautions/contra-indications) including information on measures that the user is required to take in the operating environment to reduce the likelihood of exploitation. | Do risk control solutions have the correct order or priority?<br>Note: according to MDR/IVDR, the auditee shall always implement security measures within the device rather than delegating security via IFU to the user or admin of the device. | Yes, see:<br>\- Risk table<br>\- Risk management report |
+| 3.7 | IEC 81001-5-1 cl. 7.4 | \- Determine whether security risk control measures are appropriate for reducing security risks to an acceptable level \(based on security risk acceptance policies\)<br>\- If risk controls are deemed appropriate: appropriate mitigations selected<br>\- Determine whether mitigations result in new risks or increased other risks\,<br>\- Select mitigations implemented\, effectiveness of the implemented measures verified | Are risk control measures / counter measures appropriate? | Yes, see:<br>\- Risk table<br>\- Risk management report |
+| 3.8 | MDCG 2019-16 cpt. 2.1<br>and<br>MDR Annex I (17.4) / IVDR Annex I (16.4)<br>and<br>MDR Annex I (18.8)<br>and<br>MDR Annex I (17.2) / IVDR Annex I (16.2) | ‘Key concepts involved in IT security specifically for medical devices are the following:<br>\- Confidentiality of information at rest and in transit<br>\- Integrity\, which is necessary to ensure information authenticity and accuracy \(i\.e\. non\-repudiation\)<br>\- Availability of the processes\, devices\, data\, and connected systems\.‘<br>AND<br>‘Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.’<br>AND<br>‘Devices shall be designed and manufactured in such a way as to protect, as far as possible, against unauthorised access that could hamper the device from functioning as intended.’<br>AND<br>'The Cybersecurity risks are as far as possible reduced without adversely affecting the benefit-risk ratio. The device is developed in accordance with the state of the art taking into account the principles of risk management, including information security.' | Is the security concept of the device under evaluation appropriate? | Yes, see:<br>\- Risk table<br>\- Risk management report<br>\- Software development plan |
+
+### 4. Accompanying Documentation
+
+| Item | Source | Requirement(s) | IG-NB Commentary | Manufacturer Reference for Compliance |
+| ---- | ------ | -------------- | ---------------- | ------------------------------------- |
+| 4.1 | MDCG 2019-16 cpt. 2.6<br>and<br>MDR Annex I (23.4.ab) / IVDR Annex I (20.4.1.ah) | ‘While the MDR and the IVDR provide legal obligations only with regard to manufacturers, however it should be noted that for the provision of secured healthcare services, it is important to recognize the roles and expectations of all stakeholders, such as manufacturers, suppliers, healthcare providers, patients, integrators, operators and regulators. All of these actors share responsibilities for ensuring a secured environment for the benefit of patients’ safety.’<br>AND<br>The instructions for use shall contain all of the following particulars: ‘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 unauthorised access, necessary to run the software as intended.’ | Are the responsibilities of manufacturer, integrator and users correctly reflected in the IFU?<br>Note: in cases where the medical device relies on the operating environment to provide essential IT security controls, this is appropriately stated in the accompanying technical documentation. | Yes, see:<br>\- Instructions for use / user manual |
+| 4.2 | MDCG 2019-16 cpt. 4.2 | ‘The requirements regarding the instructions for use are outlined in the following articles of Annex I’ | Does the accompanying documentation appropriately contain the following (if applicable):<br>\- Any residual cybersecurity risk communicated as limitation\, contraindication\, precaution or warning<br>\- Information about product installation such as configuration of security features \(CNFS\)\. Note: this does NOT mean the documentation /or provisioning of passwords for assessment in the accompanying documents\. Also include required information about any necessary 3rd party software such as anti\-virus software\, firewall\, malware detection/protection \(MLDP\) and minimum requirements for OS\, workstation\, peripherals\.<br>\- Procedures for using the medical device in fail\-safe mode / action plan for users to follow in case of alert messages<br>\- Information about user requirements in terms of training / required skills<br>\- Instruction on installing \(cybersecurity\) updates & patches \(CSUP\)<br>\- The environment of use \(home environment\, healthcare facility\, etc\.\)<br>\- A description of data backup \(DTBK\) and restore features<br>\- User roles incl\. privileges<br>\- Information about logging | Yes, see:<br>\- Instructions for use / user manual<br>\- User training |
+
+### 5. Lifecycle (Relevant Output Documents)
+
+| Item | Source | Requirement(s) | IG-NB Commentary | Manufacturer Reference for Compliance |
+| ---- | ------ | -------------- | ---------------- | ------------------------------------- |
+| 5.1 | IEC 62304 cl. 8.1.2 | 'Document for each SOUP configuration item being used (incl. standard libraries): title, manufacturer, unique SOUP designator." | Has the manufacturer documented all SOUP components? | Yes, see:<br>\- SOUP |
+| 5.2 | MDCG 2019-16 cpt. 3.7<br>and<br>IEC 81001-5-1 cl. 5.7.5 | ‘The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing.’<br>AND<br>'Documented means of ensuring objectivity of the test effort for security requirements testing, known vulnerability scanning and penetration testing.' | \- Is the penetration test report available and appropriate?<br>\- Is the penetration test covering all applicable attack vectors?<br>\- Is the tester appropriately skilled?<br>\- Is the tester independent?<br>\- Are appropriate tools used?<br>\- Is enough time / resources utilized? Is appropriate Fuzz Testing conducted where applicable?<br>Note 1: Common penetration testing methodologies such as open-source security testing methodologies (OSSTMM), MASTG, phased structured approaches such as penetration testing execution standard (PTES) methodologies should be adapted as appropriate for the medical device until appropriate standards are available.<br>Note 2: The penetration test should consider any special constraints relating to the medical device(s) such as the safety of the patient and others as well as clinical performance.<br>Note 3: ISO 17025 accredited test laboratories with appropriate capability and competence for medical device penetration testing should be used once available. | Security verification and validation was performed as part of system testing. See system test results. |

package/vendor/dev-docs-templates/templates/mdr_docs/CA/risk-management-report.md

@@ -0,0 +1,111 @@
+# 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. Annec C of ISO 14971 was reviewed for potentially applicable scenarios. 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\>*.
+
+---
+
+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.