@neobiotechlabs/neobiotech-dev-agent 0.1.7

package/vendor/dev-docs-templates/templates/mdr_docs/global/qms/sop-post-market-surveillance.md

@@ -0,0 +1,159 @@
+# 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.
+
+|                                |                                                          |
+|--------------------------------|----------------------------------------------------------|
+| **Process Owner**              | *\<enter role of process owner\>*                        |
+| **Key Performance Indicators** | *\<enter KPIs to be tracked for the Management Review\>* |
+
+**Regulatory References:**
+
+|                        |                                                                    |
+|------------------------|--------------------------------------------------------------------|
+| EU Regulation 2017/745 | Art. 83 - 86 (Post-market surveillance), Art. 88 (Trend reporting) |
+
+## General Considerations
+
+This process is followed for each product separately, meaning that for each product, a Post-Market
+Surveillance Plan and Post-Market Surveillance Report (class I) or Periodic Safety Update Report (class IIa
+and higher) are created and continuously updated.
+
+> Note: For class I devices, you could specify a longer update interval, e.g. once every two or three 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.
+
+
+## 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 and a Post-Market Surveillance Report is
+compiled. At least, this report should be updated when new relevant data has been identified.
+
+The plan should be created based on the Post-Market Surveillance Plan Template, following MDR Annex III,
+Section 1.
+
+|              |                                                                     |
+|--------------|---------------------------------------------------------------------|
+| Participants | QMO,<br>Product Manager                                             |
+| Input        | Device Description<br>Clinical Evaluation<br>Risk Management Report |
+| Output       | Post-Market Surveillance Plan                                       |
+
+### 2. Collect Information and Initiate Actions
+
+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 statistical relevance 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. If a CAPA
+  is identified based on Post-Market Surceillance information, the competent authority and/or Notified Body
+  are informed.
+* **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,<br>Product Manager                                               |
+| Input        | Post-Market Surveillance Plan<br>Post-Market Surveillance Information |
+| Output       | Evaluated Information                                                 |
+
+### 3. Conduct Trend Analysis
+
+All collected post-market surveillance information must be reviewed against the device's risk management file. Any statistically significant increase in the frequency or severity of non-serious incidents and expected undesirable side effects must reported to the competent authority following the SOP Vigilance, if:
+
+* The non-serious incident or undesirable side effect could have a significantly negative impact on the benefit-risk-profile of the device (see Annex I, Para. 1 + 5 MDR); AND
+* The non-serious incident or undesirable side effect led or could have lead to unacceptable risks for patients, users or others when weighed against the intended benefits.
+
+The significant increase is established in comparison to the assumptions for frequency or severity of such incidents during the product lifetime, which are specified in the device's risk management file. Records of the conducted trend analysis shall be stored with other TechDoc records of the device.
+
+|              |                                                                                                            |
+|--------------|------------------------------------------------------------------------------------------------------------|
+| Participants | QMO                                                                                                        |
+| Input        | Collected information                                                                                      |
+| Output       | Conducted trend analysis<br>Reported statistically significant trend to competent authority (if necessary) |
+
+### 4. Compile Post-Market Surveillance Report (PMSR)
+
+For class I devices, the Product Manager finalizes the Post-Market Surveillance Report (PMSR), which is at
+least reviewed by the Person Responsible for Regulatory Compliance (PRRC). The report should contain at least
+the following information:
+
+* main findings and analyses of post-market surveillance activities throughout the surveillance interval as
+  set out in the Post-Market Surveillance Plan
+* a rationale and description of any preventive and corrective actions taken
+
+|              |                                     |
+|--------------|-------------------------------------|
+| Participants | QMO,<br>Product Manager             |
+| Input        | Collected and evaluated information |
+| Output       | Post-Market Surveillance Report     |
+
+### 5. Compile Periodic Safety Update Report (PSUR)
+
+For class IIa devices and higher, 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 as set out in the
+  Post-Market Surveillance Plan
+* a rationale and description of any preventive and corrective actions taken
+* conclusion regarding implications for the risk management and clinical evaluation of the product, in
+  particular, the overall residual risk and benefit-risk determination
+* findings from the Post-Market Clinical Follow-Up
+* the sales volume of the device, e.g. amount of users and, where practicable, the usage frequency of the
+  device.
+
+|              |                                     |
+|--------------|-------------------------------------|
+| Participants | QMO,<br>Product Manager             |
+| Input        | Collected and evaluated information |
+| Output       | Periodic Safety Update Report       |
+
+---
+
+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/global/qms/sop-software-problem-resolution.md

@@ -0,0 +1,99 @@
+# 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 Owner**              | *\<enter role of process owner\>*                        |
+| **Key Performance Indicators** | *\<enter KPIs to be tracked for the Management Review\>* |
+
+## 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 (PRRC) must
+be informed who subsequently assesses it according to the SOP Vigilance.
+
+| 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 bug fix is implemented. If the fix includes a change to an existing product, it is handled according to
+SOP Change Management.
+
+After the bug fix 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 |                                |
+
+---
+
+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.