@neobiotechlabs/neobiotech-dev-agent 0.1.7

package/vendor/dev-docs-templates/templates/mdr_docs/ER/global/bug-fixes-documentation-list.md

@@ -0,0 +1,35 @@
+# Bug Fixes Documentation List
+
+| Regulations          | Document Section |
+|----------------------|------------------|
+| IEC 62304, Chapter 9 | All              |
+
+## Summary
+
+This list is used to document the evaluation and implementation of all bug fixes according to the company's
+change management process.
+
+## Documentation of Bug Fixes
+
+| Evaluation Categories                                                         |                                                          |                                                      |       |
+|-------------------------------------------------------------------------------|----------------------------------------------------------|------------------------------------------------------|-------|
+| Bug ID                                                                        | #B01                                                     | #B02                                                 | (...) |
+| Bug Description                                                               | Hovering over button should display info box but doesn't | Users do not understand how to use text field        |       |
+| Occurrence Date and Time                                                      | 01-04-2021                                               | 16-03-2021                                           |       |
+| Corrective Action                                                             | Display of information when hovering                     | Renaming text field                                  |       |
+| Preventive Action                                                             | Added test scenario #T123 *(link file)*                  | Added usability test scenario #U123 *(link file)*    |       |
+| Affected Software Requirement                                                 | #REQ192 "Display user information (...)"                 | #REQ193 "Provide field to document information (..." |       |
+| Corresponding Implementation Ticket<br>*(optional, e.g. Github Pull Request)* | (...)                                                    | (...)                                                |       |
+| Corresponding Test Documentation<br>*(e.g. System Test ID #121)*              | #T123                                                    | #T132                                                |       |
+| Test Completed (When / By Whom)                                               | 2021-04-15 by John Doe                                   | 2021-04-15 by John Doe                               |       |
+| Affected Risk Documentation                                                   | -                                                        | Risk ID #369 "User does not understand XYZ"          |       |
+| Preliminary Incident Assessment by MDSO                                       | No incident                                              | No incident                                          |       |
+| Preliminary Significance Assessment by QMO                                    | Not significant                                          | Not significant                                      |       |
+| Release Date of Updated Software Version                                      | 2021-04-16                                               | 2021-04-16                                           |       |
+
+---
+
+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/ER/global/change-evaluation-list.md

@@ -0,0 +1,100 @@
+# Change Evaluation List
+
+| Regulation / Guidance                                             | Document Section |
+|-------------------------------------------------------------------|------------------|
+| Medical Device Regulation, Annex IX<br>Chapter II Section 4.10    | All              |
+| MDCG Guidance Document 2020-03                                    | All              |
+
+## Summary:
+
+This list is used to document the evaluation of all regular change requests according to the company's change
+management process.
+
+## Evaluation of Product Changes
+
+> Disclaimer for Use #1: You may want to separate your lists for product and organizational changes, as you
+> should release a new list for every product version. This is to separately identify all changes related to
+> that specific version. Each product version list should ideally be attached to the respective technical
+> documentation file.
+
+> Disclaimer for Use #2: If any of the below mentioned categories are answered with YES, this indicates that
+> your change must be classified as significant.
+
+> Disclaimer for Use #3: In the example content filled into the table below, "PCR" stands for "Product Change
+> Request" and "OCR" stands for "Organization Change Request".
+
+**Please note:**
+
+* YES in the first two categories (intended use / essential requirements / GSPR) always leads to a significant
+  change.
+* If the device is modified (a) to correct an error, for which there is a safety risk to the patient if the
+  error is not corrected or (b) as part of field safety corrective actions for an incident, the change is
+  discussed with the Notified Body to determine the significance of the change. If no Notified Body was
+  involved in the conformity assessment process of the device, the change is treated as a significant change.
+
+| Evaluation Categories                                                                                                                                                                                     |                                                                              |                                                                |       |
+|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------|----------------------------------------------------------------|-------|
+| **Change Request ID**                                                                                                                                                                                     | #PCR01                                                                       | #PCR02                                                         | (...) |
+| **Change Request Description**                                                                                                                                                                            | Performance update of machine learning algorithm model                       | Additional integrability of device with new clinical IT-system |       |
+| **Overall Evaluation Outcome**                                                                                                                                                                            | **Not significant**                                                          | **Significant**                                                |       |
+| Does the change alter specifications provided in the Intended Use? (Chart A of MDCG 2020-03, e.g. new user or patient population)                                                                         | No                                                                           | No                                                             |       |
+| Does the change affect conformity with the General Safety and Performance Requirements?                                                                                                                   | No                                                                           | No                                                             |       |
+| Does change implementation require further clinical or usability data to support safety and performance? (Chart B of MDCG 2020-03)                                                                        | No, but internal validation showed that performance on same metrics improved | Yes                                                            |       |
+| Do new risks require risk control measures or are existing risks negatively affected? (Chart B of MDCG 2020-03)                                                                                           | No                                                                           | Yes                                                            |       |
+| Does the change alter built-in control mechanisms or alarms? (Chart B of MDCG 2020-03)                                                                                                                    | No                                                                           | No                                                             |       |
+| Does the change modify an operating principle or sources of energy? (Chart B of MDCG 2020-03)                                                                                                             | No                                                                           | No                                                             |       |
+| Does the change introduce a new or major change of the operating system or of any component? (Chart C of MDCG 2020-03, e.g. major SOUP update)                                                            | No                                                                           | No                                                             |       |
+| Does the change introduce a new or modified architecture or database structure, change of an algorithm? (Chart C of MDCG 2020-03, e.g. changes to prediction principle of an algorithm model)             | No, same prediction model                                                    | No                                                             |       |
+| Does the change replace previously required user input by a closed-loop algorithm? (Chart C of MDCG 2020-03)                                                                                              | No                                                                           | No                                                             |       |
+| Does the change introduce a new diagnostic or therapeutic feature, or new channel of interoperability?<br>(Chart C of MDCG 2020-03)                                                                       | No                                                                           | Yes, new channel of interoperability                           |       |
+| Does the change introduce a new user interface or presentation of data? (Chart C of MDCG 2020-03)                                                                                                         | No                                                                           | No                                                             |       |
+| Does change implementation involve changes in critical suppliers? (Chart D of MDCG 2020-03)                                                                                                               | No                                                                           | No                                                             |       |
+| Does the change impact the way medical data is read or interpreted by the user, such that the treatment or diagnosis of the patient may be altered when compared to the previous version of the software? | Yes, but only improved accuracy in supported diagnosis                       | No                                                             |       |
+
+## Evaluation of Organizational Changes
+
+Please note: YES in the first two categories (Intended Use / GSPR) always leads to a significant
+change.
+
+| Evaluation Categories                                                                                                                                                                                                                                                                                                        |                                    |                                                                        |       |
+|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------|------------------------------------------------------------------------|-------|
+| **Change Request ID**                                                                                                                                                                                                                                                                                                        | #OCR1                              | #OCR2                                                                  | (...) |
+| **Change Request Description**                                                                                                                                                                                                                                                                                               | Change of Company Business Address | Adding a new compliance process to comply with anti-bribery provisions |       |
+| **Overall Evaluation Outcome**                                                                                                                                                                                                                                                                                               | **Significant**                    | **Not significant**                                                    |       |
+| Does the change affect QMS conformity with the General Safety and Performance Requirements (MDR)?                                                                                                                                                               | No                                 | No                                                                     |       |
+| Does the change affect product conformity with the General Safety and Performance Requirements (MDR) or the approved type / design?<br>       | No                                 | No                                                                     |       |
+| Does the change relate to manufacturing processes, technologies, facility or equipment in a way that could impact product safety and performance?                                                                                                                                              | No                                 | No                                                                     |       |
+| Does the change affect the location of the company's activities?<br>                                                                                                                                                                                                                           | Yes                                | No                                                                     |       |
+| Does change implementation involve changes in critical suppliers?<br>(Chart D of MDCG 2020-03)                                                                                                                                                                                                  | No                                 | No                                                                     |       |
+| Does the change affect the arrangements implemented to achieve continued compliance of the QMS with the relevant harmonized standards and/or MDR requirements (e.g. design verification, design validation, organizational structure, process interaction, quality control procedures)?<br> | No                                 | No                                                                     |       |
+
+> Based on the linked guidance documents, examples for non-significant changes are:
+>
+> * a software change that only introduces non-therapeutic and/or non-diagnostic features such as printing,
+>   faxing, improved image clarity, reporting format or additional language support
+> * a software change that only modifies the appearance of the user interface with negligible risk of
+>   impacting the diagnosis or therapy delivered to the patient
+> * a software change only intended to correct an inadvertent logic error that does not pose a safety risk and
+>   brings the system back into specification
+> * a software change that consists only of tightening of design specifications within specified tolerances
+>   and where there is no creation of new features
+> * changes to labelling to include additional languages required in other regulatory jurisdictions
+> * minor changes to clarify the existing wording of warnings and precautions. However, in the case where
+>   these changes add or remove a contraindication, or remove a warning or precaution, the Notified Body shall
+>   be involved.
+
+
+> Based on the linked guidance documents, examples for significant changes are:
+>
+> * an alteration in software that modifies an algorithm impacting the diagnosis or the therapy delivered
+> * introduction or removal of a new alarm function from the software such that a response to the new
+>   configuration may change the treatment of the patient in comparison to the previous version of the
+>   software
+> * medical data is presented in a new format, new dimension or new measuring unit.
+
+---
+
+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/ER/global/list-of-known-anomalies.md

@@ -0,0 +1,29 @@
+# List of Known Anomalies
+
+> This template is supposed to give you an idea of the structure. Don't use Microsoft Word - this is thought
+> as an excel / sheets file.
+
+This list shows technical errors ("bugs") of the current device which were decided not to be corrected before the
+release of the latest version.
+
+It, therefore, serves as an overview and as a documentation of reasoning for non-correction.
+
+**Regulatory references:**
+
+|                |                            |
+|----------------|----------------------------|
+| IEC 62304:2006 | Para. 5.7.5, 5.8.2 / 5.8.3 |
+
+## Anomalies
+
+| Title            | Description                                                                                                                                                          | Impact / Hazard                                                                                                                                    | Discovery (Date, How, By Whom)                         | Proposed Correction                | Justification for Delay                                                                                         | Timeline             |
+|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|------------------------------------|-----------------------------------------------------------------------------------------------------------------|----------------------|
+| Default language | If the app is installed on a smartphone with unsupported language, the default language is German. Users then have to navigate to the language settings for changes. | Users in countries with unsupported language are likely not German-speaking and may not be able to use the app without changing language settings. | 2022-04-01 during usability testing by Product Manager | Change default language to English | Per appstore setting, the app is currently only available in countries whose predominant language is supported. | Next version release |
+| (...)            | (...)                                                                                                                                                                | (...)                                                                                                                                              | (...)                                                  | (...)                              | (...)                                                                                                           | (...)                |
+
+---
+
+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/ER/sprint/algorithm-validation-report.md

@@ -0,0 +1,170 @@
+> DISCLAIMER:
+>
+> You may not need this template. It's aimed companies that develop devices including ML algorithms. Why do
+> they need this template?
+>
+> Due to the "blackbox" nature of many of those algorithms, their functionalities typically can't be verified
+> in the same sense as code reviews can verify correct coding in the world of old-school software
+> development. That's why they can only be validated by subjecting the model to rigorous testing on separate
+> test datasets. This report is the place to document all the results (e.g. sensitivity, specificity,
+> accuracy, ROC curve values, discussion of outlayers, edge cases, etc.). Side note: there's a disconnect
+> between what data science and regulatory affairs understands as validation and verification. Don't get
+> confused!
+
+# 1. General Information
+
+This document describes the specification of our machine learning (algorithm) model and its testing strategy.
+
+> Keep in mind that the results of the algorithm validation should also serve as input to and be referenced in
+> your clinical evaluation / performance evaluation report.
+
+**Regulatory references:**
+
+| ISO 13485:2016 Section   | Document Section |
+|--------------------------|------------------|
+| 6.2; 7.3.2               | 2.1              |
+| 7.3.7                    | 2.3; 3.1; 3.2    |
+| 4.2.3; 5.2; 7.2.1; 7.3.3 | 2.4              |
+| 4.1; 7.3.6               | 3                |
+| 7.3.2; 7.3.6; 7.3.7      | 5                |
+
+| ISO 14971:2019 Section | Document Section |
+|------------------------|------------------|
+| 4.3                    | 2.1              |
+| 5.2                    | 2.4              |
+
+| ISO 82304:2016 Section | Document Section |
+|------------------------|------------------|
+| 6.1                    | 2.1              |
+
+| ISO 62366-1:2015 Section | Document Section |
+|--------------------------|------------------|
+| 5.1; 5.2                 | 2.4              |
+
+| ISO 62304:2006 Section | Document Section |
+|------------------------|------------------|
+| 5.3; 8.1.2             | 2.2              |
+| 5.2                    | 2.4              |
+
+| ISO/IEC 24028:2020 Section | Document Section |
+|----------------------------|------------------|
+| 9.8.1; 10.5                | 3.1; 3.2         |
+| 9.8.2.1                    | 3.2              |
+| 9.8.2.2                    | 4                |
+
+**Relevant other documentation:**
+
+* SOP Software Development
+* Software Development and Maintenance Plan
+* SOUP List
+
+# 2. Development Resources
+
+For more context information, refer to the device’s software development and maintenance plan.
+
+## 2.1. Developer Team
+
+| Name  | Role  | Qualification |
+|-------|-------|---------------|
+| (...) | (...) | (...)         |
+
+## 2.2. SOUP / Frameworks
+
+| Name    | Version |
+|---------|---------|
+| PyTorch | (...)   |
+
+## 2.3. Data
+
+| Count | Description                                           |
+|-------|-------------------------------------------------------|
+|       | \<e.g. annotated heart rate dataset from a wearable\> |
+
+## 2.4. Development Planning
+
+Optional: remove or add to the following sub-paragraphs as appropriate.
+
+**Intended Purpose**
+
+> Reference intended use; describe intended task the model should solve.
+
+(...)
+
+**Clinical Environment**
+
+> Reference clinical evaluation plan; describe clinical context in which the model will be used.
+
+(...)
+
+**Software Architecture**
+
+> Reference software architecture (diagram); describe how the model will be embedded in the overall system and
+> how it will interact with other software components.
+
+(...)
+
+**Quality Requirements**
+
+> Reference clinical evaluation plan; describe quality criteria that shall apply to the model, for example,
+> quantify values for sensitivity / specificity, AUC, positive/negative predictive value, accuracy,
+> repeatability. Also, provide justification for why certain parameters may not apply and compare your
+> approach to the current state of the art / technology.
+
+(...)
+
+# 3. Data Management
+
+## 3.1. Data Acquisition
+
+> Describe how you acquired your data (sources, inclusion / exclusion criteria, possible biases, data
+> protection measures, etc). Give a rough estimate of what size of datasets are required.
+>
+> If applicable, reference relevant QMS processes.
+
+(...)
+
+## 3.2. Data Annotation
+
+> Describe how data is labeled and how you determined the ground truth. Further, you can describe: labeling
+> requirements (quality criteria), qualification / training of staff involved, quality assurance for correct
+> labeling. If applicable, reference relevant QMS processes.
+
+(...)
+
+## 3.3. Data Pre-Processing
+
+> Describe how you pre-processed data. Possible steps may include: anonymization / pseudonymization, removing
+> data elements, converting data formats or units, handling missing values or data outliers. How did you
+> divide data into training, validation and test data. If applicable, reference relevant QMS processes.
+
+(...)
+
+# 4. Algorithm Model Training and Description
+
+> Describe your algorithm model. For example: which type of model (e.g. CNN) is used? Optionally, add a graph
+> or diagram to explain the model architecture. Describe model training; e.g. selection of features, (most
+> important) hyperparameters, etc.
+
+(...)
+
+# 5. Algorithm Model Evaluation
+
+> Describe how testing is done: describe your test data set, which metrics are used for evaluation and which
+> values are deemed acceptable.
+
+(...)
+
+# 6. Conclusion
+
+> Discuss your evaluation results: why do they meet predefined quality criteria, why is the model fit for
+> purpose in accordance with the medical device’s intended use? Take into account possible risks, biases and
+> limitations.
+
+(...)
+
+---
+
+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/ER/sprint/checklist-software-release.md

@@ -0,0 +1,52 @@
+# Checklist: Software Release
+
+| Classes | IEC 62304:2006 Section | Document Section |
+| ------- | ---------------------- | ---------------- |
+| A, B, C | 5.8.1 | (All) |
+| A, B, C | 5.8.2 | (All) |
+| A, B, C | 5.8.3 | (All) |
+| A, B, C | 5.8.4 | (All) |
+| B, C | 5.8.5 | (All) |
+| B, C | 5.8.6 | (All) |
+| A, B, C | 5.8.7 | (All) |
+
+## Summary
+
+This checklist is used to verify that documentation and activities are complete before releasing a new version of the product.
+
+> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The main point is that, at minimum, the items below should be checked (and documented) before you release a new version of your software.
+
+> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty much the bare minimum to be 62304-compliant.
+
+## Checklist
+
+The following documents are up to date:
+
+> The table below shows examples only. Add - or reference - a list of all your required TechDoc records.
+
+| Item | Yes | No | Comment |
+| ---- | --- | --- | ------- |
+| Device Description |  |  |  |
+| Clinical Evaluation |  |  |  |
+| Declaration of Conformity |  |  |  |
+| (...) |  |  |  |
+
+The following activities have been performed:
+
+| Item | Yes | No | Comment |
+| ---- | --- | --- | ------- |
+| All relevant functionalities of the software have been specified; the Software Requirement List is complete and has been reviewed. |  |  |  |
+| All relevant risks (including risks of known anomalies) have been evaluated; the Risk Management Report is complete. |  |  |  |
+| Verification (as software system testing) has been completed. |  |  |  |
+| Design control traceability is ensured:<br>Stakeholder requirements can be traced to software requirements.<br>Software requirements can be traced to system tests.<br>Software requirements can be traced to software code implementation / software code reviews.<br>Software requirements can be traced to risks and risk control measures.<br>Stakeholder requirements can be traced to usability tests.<br>Hazard-related use scenarios can be traced to usability tests.<br>Hazard-related use scenarios can be traced to risks and risk control measures. |  |  |  |
+| A version number as defined in the Software Development Plan has been assigned and added as a tag to git. |  |  |  |
+| Software is registered with a Notified Body. |  |  |  |
+| If release includes substantial change: Notified Body has been informed. |  |  |  |
+| Label is applied correctly including CE marking. |  |  |  |
+
+---
+
+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/ER/sprint/checklist-software-requirements-review.md

@@ -0,0 +1,50 @@
+# Checklist: Software Requirements Review
+
+| Classes | IEC 62304:2006 Section | Document Section |
+|---------|------------------------|------------------|
+| A, B, C | 5.2.6                  | (All)            |
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 7.3.3                  | (All)            |
+| 7.3.5                  | (All)            |
+
+## 1. Summary
+
+This checklist is used to review (verify) software requirements prior to implementation.
+
+> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill
+> this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The
+> main point is that, at minimum, the items below should be filled out before you start implementing software
+> requirements.
+
+> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty
+> much the bare minimum to be 62304-compliant.
+
+## 2. Checklist
+
+| Software Requirements...                                                      | Yes | No | Comment |
+|-------------------------------------------------------------------------------|-----|----|---------|
+| are traceable to design input or risk control measures.                       |     |    |         |
+| are complete.                                                                 |     |    |         |
+| are understandable, uniquely identifiable and do not contradict each other.   |     |    |         |
+| include user interface requirements (mockups, wireframes, etc.), if relevant. |     |    |         |
+| include IT security requirements, if relevant.                                |     |    |         |
+| are testable and include acceptance criteria.                                 |     |    |         |
+
+# 3. Comments
+
+\<Insert comments if applicable\>
+
+# 4. Result
+
+[ ] Software Requirements passed\
+[ ] Software Requirements not passed\
+[ ] Software Requirements passed with the following obligations: \<Insert if applicable\>\
+
+---
+
+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/ER/sprint/software-architecture-checklist.md

@@ -0,0 +1,41 @@
+# Software Architecture Checklist
+
+**Regulatory references:**
+
+IEC 62304, para. 5.3.6 [class B, C]
+
+**Relevant other documentation:**
+
+* SOP Software Development
+* User needs / stakeholder requirements
+* Design input / software requirements
+* Software architecture description
+* (...)
+
+# 1. Checklist
+
+| Criteria                                                                                                 | Pass / Fail             |
+|----------------------------------------------------------------------------------------------------------|-------------------------|
+| The software architecture is in agreement with the software requirements.                                | ( ) Yes<br>( ) Improve: |
+| All software systems are listed and their respective safety class is stated.                             | ( ) Yes<br>( ) Improve: |
+| All software components are listed and described, including interfaces.                                  | ( ) Yes<br>( ) Improve: |
+| All software units are listed and described.                                                             | ( ) Yes<br>( ) Improve: |
+| (Optional) Further architecture is described, e.g. databases, security and data protection requirements. | ( ) Yes<br>( ) Improve: |
+| The software architecture can be implemented with our given resources.                                   | ( ) Yes<br>( ) Improve: |
+
+# 2. Comments
+
+\<Insert comments if applicable\>
+
+# 3. Results
+
+( ) Software Architecture passed\
+( ) Software Architecture not passed\
+( ) Software Architecture passed with the following obligations: \<Insert if applicable\>\
+
+---
+
+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.