@neobiotechlabs/neobiotech-dev-agent 0.1.7

package/vendor/dev-docs-templates/templates/mdr_docs/global/information_security/information-security-policy-and-scope.md

@@ -0,0 +1,99 @@
+# Information Security Policy And Scope
+
+| ISO 27001:2023 Section                                                  | Document Section |
+|-------------------------------------------------------------------------|------------------|
+| 4.3 Determining the scope of the information security management system | 1.               |
+| 4.4 Information security management system                              | (All)            |
+| 5.1 Leadership and commitment                                           | 8.               |
+| 5.2 Policy                                                              | 2.               |
+| 5.3 Organizational roles, responsibilities and authorities              | 8.               |
+
+## Summary
+
+The Information Security Policy describes the scope of the Information Security Management System (ISMS), its
+documented procedures and a description of their interactions.
+
+## 1. Scope
+
+The policy described in this document outlines the framework to manage information security in *\<your company
+name\>*.
+
+This policy applies to all employees, contractors, and third-party vendors of [Organization Name] who have
+access to electronic and physical information systems and data.
+
+## 2. Policy Statement
+
+*\<your company name\>* commits to maintaining the confidentiality, integrity, and availability of all its
+information assets. This is achieved through:
+
+* Implementing a comprehensive Information Security Management System (ISMS) compliant with ISO/IEC 27001:2023
+  standards.
+* Regularly assessing the information security risks and implementing the appropriate measures to mitigate
+  identified risks.
+* Ensuring that information security is an integral part of all IT and business processes.
+* Providing ongoing training and support to all staff to ensure they understand their roles and
+  responsibilities in safeguarding sensitive information.
+* Regularly reviewing and updating the ISMS to address new security challenges and business changes.
+
+## 3. Information Security Principles
+
+* Confidentiality: Ensuring that information is accessible only to those authorized to have access.
+* Integrity: Safeguarding the accuracy and completeness of information and processing methods.
+* Availability: Ensuring that authorized users have access to information and associated assets when required.
+
+## 4. Risk Management
+
+The organization will regularly carry out risk assessments to identify, evaluate, and address risks associated
+with information security.
+
+## 5. Incident Management
+
+A structured approach will be followed to handle security breaches or incidents, which includes incident
+reporting, investigation, and mitigation strategies to prevent future occurrences.
+
+## 6. Compliance
+
+Compliance with this policy will be monitored and reviewed as part of the ongoing performance evaluation
+process. Violations of this policy will result in disciplinary action, which may include termination and legal
+action, depending on the severity of the breach.
+
+## 7. Policy Review
+
+This policy will be reviewed annually or in response to significant organizational or technological changes to
+ensure its continuing suitability, accuracy, and effectiveness.
+
+## 8. Organizational Roles, Responsibilities and Authorities
+
+> 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.
+>
+> Minimum requirement information: required qualification and description of tasks related to QMS process
+> involvement If applicable, add: report / authority, access rights, etc.
+
+| Role            | People                    |
+|-----------------|---------------------------|
+| CEO             | Steve Jobs                |
+| CTO             | Steve Wozniak             |
+| ISO             | Oliver Eidel              |
+
+All C-level roles (CEO, CTO, CMO) are referred to as the Management. Management is generally responsible to
+endorse and support the Information Security Policy by providing the necessary resources and authority to
+implement it.
+
+The Information Security Officer (ISO) is responsible for maintaining the ISMS and ensuring the policy is
+implemented, monitored, reviewed, and updated.
+
+All Employees are required to adhere to this policy and report any security breaches or incidents to the
+designated authority.
+
+Required qualification for this role:
+
+* Fluent in German and English language
+* Training in the field of information security management
+
+---
+
+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/quality-manual-policy-objectives.md

@@ -0,0 +1,187 @@
+# 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
+
+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?                                           |
+|-----------------------------|-----------------------------------------------------------|
+| EU Regulation 2017/745      | Regulation for medical devices for human use              |
+| EU Regulation 2021/2226     | Regulation for electronic instructions for use            |
+| EN ISO 13485:2016           | QMS required by essential requirements of MDD/MDR         |
+| EN 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
+ * 7.5.11 Preservation of product
+
+## 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.
+>
+> In addition, the policy should include a commitment to meet legal requirements, keep the QMS up to date and
+> define quality objectives to work towards.
+
+### 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.
+
+### Key Performance Indicators (KPIs)
+
+> Auditors might ask you: how do you keep track of a quality objective, to see if it was achieved or not?  The
+> answer is: Key Performance Indicators. As part of your management review, you have to review all QMS
+> processes plus your quality policy and objectives at least annually. Now, you can meet both requirements at
+> the same time by defining KPIs for your QMS processes. You can then argue that by achieving your KPIs, you
+> make sure that your processes run well, which also meets your quality objectives.
+
+> These are your action items:
+> 1. Make sure to define at least one KPI for each QMS process.
+> 2. Make sure each quality objectives translates into at minimum one process KPI. Where there's no
+>    corresponding process for a quality objective, you define additional KPIs that are not process-related.
+> 3. You can document those KPIs either in each SOP or in a separate overview sheet. For example, you can use
+>    the template for a management review report for that purpose.
+>
+> Also see regulatory requirements: ISO 13485, para. 4.1.3.a (process KPIs) and para. 5.6.2 (management review
+> input).
+>
+> In this section here, describe where you define your KPIs and how you keep track of them. For example, say
+> that you define KPIs in every single SOP or reference to a separate, central overview sheet. Ideally, KPIs
+> are tracked by each process owner independently.
+
+## 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.
+>
+> Minimum requirement information: required qualification and description of tasks related to QMS process
+> involvement If applicable, add: report / authority, access rights, etc.
+
+| 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 for:
+
+* ensuring that processes needed for the company’s quality management system are documented
+* reporting to top management on the effectiveness of the quality management system and any need for
+  improvement
+* ensuring the promotion of awareness of applicable regulatory requirements and QMS requirements throughout the
+  organization.
+
+Required qualification for this role:
+
+* Fluent in German and English language
+* At minimum one year of professional experience in the fields of quality management and regulatory affairs
+
+> 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 highly company-specific and might therefore be currently incomplete.
+>
+> **Important Note:**
+>
+> Also mention if one of these processes is outsourced to a third party (typical examples: internal auditing
+> or clinical evaluation done by a regulatory consultant, software development done by an external agency; see
+> ISO 13485:2016, para. 4.1.5 for more context).
+
+| SOP                                        | Process Category | Internal / Outsourced |
+|--------------------------------------------|------------------|-----------------------|
+| SOP Corrective and Preventive Action       | Management       | Internal              |
+| SOP Clinical Evaluation                    | Core             | Outsourced (?)        |
+| SOP Product Certification and Registration | Core             | Internal              |
+| SOP Change Management                      | Core             | Internal              |
+| SOP Deployment                             | Core             | Internal              |
+| SOP Document and Record Control            | Support          | Internal              |
+| SOP Integrated Software Development        | Core             | Internal              |
+| SOP Feedback Management                    | Core             | Internal              |
+| SOP Internal Auditing                      | Management       | Outsourced (?)        |
+| SOP Management Review                      | Management       | Internal              |
+| SOP Post-Market Surveillance               | Management       | Internal              |
+| SOP Problem Resolution                     | Core             | Internal              |
+| SOP Software Validation                    | Support          | Internal              |
+| SOP Update of Regulations                  | Support          | Internal              |
+| SOP Vigilance                              | Core             | Internal              |
+
+---
+
+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-capa.md

@@ -0,0 +1,112 @@
+# 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 Owner**              | *\<enter role of process owner\>*                        |
+| **Key Performance Indicators** | *\<enter KPIs to be tracked for the Management Review\>* |
+
+## 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 and Immediate Action
+
+If immediate action is necessary (e.g. field safety corrective action or a notification to authorities according to SOP Vigilance), 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 |
+
+---
+
+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-change-management.md

@@ -0,0 +1,128 @@
+# 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.
+
+|                                |                                                          |
+|--------------------------------|----------------------------------------------------------|
+| **Process Owner**              | *\<enter role of process owner\>*                        |
+| **Key Performance Indicators** | *\<enter KPIs to be tracked for the Management Review\>* |
+
+## 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 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”
+
+## 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)
+* Changes to the QMS
+
+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.
+
+If the change request relates to the change of parts of the QMS, the change is assessed with the second part of the change evaluation list for "organizational changes".
+
+| 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.
+
+---
+
+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-clinical-evaluation.md

@@ -0,0 +1,102 @@
+| Regulatory Requirement | Document Section |
+|------------------------|------------------|
+| MDR Annex XIV          | All              |
+| MEDDEV 2.7/1, rev. 4   | All              |
+| MDCG 2020-6            | All              |
+
+## Summary
+
+This SOP describes the development of medical devices in accordance with regulatory requirements of 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 Owner**              | *\<enter role of process owner\>*                        |
+| **Key Performance Indicators** | *\<enter KPIs to be tracked for the Management Review\>* |
+
+## 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. The clinical evaluation shall consider at least the following points:
+
+* 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).
+
+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.) |
+
+---
+
+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.