@neobiotechlabs/neobiotech-dev-agent-codex 0.1.39

package/vendor/dev-docs-templates/templates/mdr_docs/EA/software-requirements-list.md

@@ -0,0 +1,156 @@
+# Software Requirements List (SRS): {PRODUCT_NAME}
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.5.2 기반 SW 요구사항 명세서입니다.
+A/B/C 전체 등급에서 필수 산출물입니다.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - 시스템 요구사항 명세서(system-requirements-spec.md): 시스템 요구사항 및 SRS로 분해할 항목 확인
+  - 사용 목적 정의서(intended-use.md): 의도된 사용자, 사용 환경 확인
+  - FMEA(risk-table-fmea.md): 위험 통제 조치(Risk Control Measure)가 SRS에 반영되었는지 확인
+
+작성 지침:
+1. 모든 요구사항에 고유 ID를 부여하세요 (예: SRS-F-001, SRS-S-001)
+2. IEC 62304 카테고리를 정확히 분류하세요:
+   - Functional (기능 요구사항)
+   - Performance (성능 요구사항)
+   - User Interface (사용자 인터페이스)
+   - Security (보안 요구사항)
+   - Interface (외부 인터페이스)
+   - Regulatory (규제 준수 요구사항)
+3. 보안 요구사항(IEC 81001-5-1)은 Security 카테고리로 반드시 포함하세요
+4. 위험 통제 조치(Risk Control Measure)를 요구사항으로 추가할 때는
+   Risk Control Measure 열을 Yes로 표시하고 FMEA의 Risk ID를 연결하세요
+5. 각 요구사항은 독립적으로 검증 가능해야 합니다 (Verifiable)
+
+예시 요구사항 ID 체계:
+  SRS-F-001: 기능 요구사항 #001
+  SRS-P-001: 성능 요구사항 #001
+  SRS-UI-001: 사용자 인터페이스 요구사항 #001
+  SRS-S-001: 보안 요구사항 #001
+  SRS-I-001: 인터페이스 요구사항 #001
+  SRS-R-001: 규제 요구사항 #001
+-->
+
+**문서 번호**: {DOC_ID}
+**버전**: {VERSION} | **상태**: Draft
+**작성일**: {DATE} | **작성자**: {AUTHOR}
+**검토자**: {REVIEWER} | **승인자**: {APPROVER}
+
+---
+
+## 표준 요건 매핑 (Standard Requirements Mapping)
+
+| 표준 조항            | 제목                        | 해당 섹션        | Class   |
+| -------------------- | --------------------------- | ---------------- | ------- |
+| IEC 62304 Cl.5.2.1   | SW 요구사항 정의            | 1~3              | A, B, C |
+| IEC 62304 Cl.5.2.2   | SW 요구사항 내용            | 1~3              | A, B, C |
+| IEC 62304 Cl.5.2.3   | SW 요구사항 검토            | 전체             | A, B, C |
+| IEC 62366-1 Cl.5.2   | 사용 오류 관련 UI 특성 식별 | 2. UI 요구사항   | -       |
+| IEC 62366-1 Cl.5.6   | 사용자 인터페이스 사양      | 2. UI 요구사항   | -       |
+| IEC 81001-5-1 Cl.5.2 | 보안 요구사항               | 3. 보안 요구사항 | -       |
+| MDR Annex I 17.2     | IT 보안 고려                | 3. 보안 요구사항 | -       |
+| ISO 13485 Cl.7.2.1   | 고객 관련 프로세스          | 전체             | -       |
+
+---
+
+## 1. 기능 및 성능 요구사항 (Functional & Performance Requirements)
+
+<!-- AI AGENT: 시스템 요구사항 명세서의 SYS-F-xxx 항목을 SW 수준으로 분해하여 작성하세요
+각 요구사항은 "SW는 [조건]에서 [동작]을 [기준]으로 수행해야 한다" 형식으로 작성하면 좋습니다
+
+예시:
+- SRS-F-001: 사용자가 로그인 후 대시보드를 요청할 경우, 시스템은 3초 이내에 결과를 반환해야 한다.
+- SRS-P-001: 시스템은 동시 사용자 100명 이상을 처리할 수 있어야 한다. -->
+
+| ID        | SW 시스템   | 카테고리    | 요구사항 설명                     | 위험 통제 조치? | 관련 Risk ID | 검증 방법        |
+| --------- | ----------- | ----------- | --------------------------------- | --------------- | ------------ | ---------------- |
+| SRS-F-001 | {SW_SYSTEM} | Functional  | {REQ_DESC}                        | Yes / No        | {RISK_ID}    | System Test      |
+| SRS-P-001 | {SW_SYSTEM} | Performance | 시스템은 {N}초 이내 응답해야 한다 | No              | -            | Performance Test |
+
+---
+
+## 2. 사용자 인터페이스 요구사항 (User Interface Requirements)
+
+<!-- AI AGENT: IEC 62366-1 관점에서 사용 오류(Use Error)를 방지하는 UI 요구사항을 작성하세요
+다음 항목을 고려하세요:
+- 위험 관련 정보의 가시성 (색상, 크기, 위치)
+- 사용자 확인(Confirmation) 절차가 필요한 위험 동작
+- 오류 메시지의 명확성
+
+예시:
+- SRS-UI-001: 위험 등급 HIGH 결과는 빨간색 배경과 경고 아이콘으로 표시해야 한다.
+- SRS-UI-002: 데이터 삭제 동작 전 사용자 확인(Confirmation Dialog)을 표시해야 한다. -->
+
+| ID         | SW 시스템   | 카테고리       | 요구사항 설명 | 위험 통제 조치? | 관련 Risk ID | 검증 방법      |
+| ---------- | ----------- | -------------- | ------------- | --------------- | ------------ | -------------- |
+| SRS-UI-001 | {SW_SYSTEM} | User Interface | {UI_REQ_DESC} | Yes / No        | {RISK_ID}    | Usability Test |
+
+---
+
+## 3. 보안 요구사항 (Security Requirements)
+
+<!-- AI AGENT: MDR Annex I 17.2 및 IEC 81001-5-1 기준으로 사이버보안 요구사항을 작성하세요
+다음 항목을 필수로 포함하세요:
+- 인증 및 접근 제어
+- 데이터 암호화 (전송/저장)
+- 감사 로그
+- 취약점 패치 정책
+
+예시:
+- SRS-S-001: 시스템은 모든 사용자 세션에 JWT 기반 인증을 적용해야 한다 (exp: 1시간).
+- SRS-S-002: 모든 API 통신은 TLS 1.2 이상을 사용해야 한다.
+- SRS-S-003: 로그인 실패 5회 이상 시 계정을 30분간 잠금 처리해야 한다. -->
+
+| ID        | SW 시스템   | 카테고리 | 요구사항 설명                                      | 위험 통제 조치? | 관련 Risk ID | 검증 방법     |
+| --------- | ----------- | -------- | -------------------------------------------------- | --------------- | ------------ | ------------- |
+| SRS-S-001 | All         | Security | 모든 사용자 인증은 {AUTH_METHOD}을 사용해야 한다   | Yes             | {RISK_ID}    | Security Test |
+| SRS-S-002 | All         | Security | 모든 API 통신은 TLS 1.2 이상을 사용해야 한다       | Yes             | {RISK_ID}    | Security Test |
+| SRS-S-003 | {SW_SYSTEM} | Security | 환자 데이터는 AES-256으로 암호화하여 저장해야 한다 | Yes             | {RISK_ID}    | Security Test |
+
+---
+
+## 4. 인터페이스 요구사항 (Interface Requirements)
+
+<!-- AI AGENT: 시스템 요구사항 명세서의 SYS-I-xxx 항목을 SW 수준으로 구체화하세요
+외부 시스템(EHR, PACS, DICOM 서버 등)과의 연동 사양을 포함하세요 -->
+
+| ID        | SW 시스템 | 카테고리  | 요구사항 설명                                           | 위험 통제 조치? | 관련 Risk ID | 검증 방법        |
+| --------- | --------- | --------- | ------------------------------------------------------- | --------------- | ------------ | ---------------- |
+| SRS-I-001 | Backend   | Interface | 시스템은 {EXTERNAL_SYSTEM}과 {PROTOCOL}로 연동해야 한다 | No              | -            | Integration Test |
+
+---
+
+## 5. 규제 준수 요구사항 (Regulatory Compliance Requirements)
+
+<!-- AI AGENT: MDR 및 적용 표준에서 요구하는 SW 준수 사항을 명시하세요 -->
+
+| ID        | SW 시스템 | 카테고리   | 요구사항 설명                                            | 근거 표준 | 검증 방법       |
+| --------- | --------- | ---------- | -------------------------------------------------------- | --------- | --------------- |
+| SRS-R-001 | All       | Regulatory | SW는 IEC 62304:2006/AMD1:2015를 준수하여 개발되어야 한다 | IEC 62304 | Document Review |
+| SRS-R-002 | All       | Regulatory | SW는 ISO 14971:2019에 따른 위험 관리를 수행해야 한다     | ISO 14971 | Document Review |
+
+---
+
+## 6. 추적성 (Traceability)
+
+이 문서의 요구사항은 다음 문서와 연결된다:
+
+| 연결 방향         | 연결 문서                                                 |
+| ----------------- | --------------------------------------------------------- |
+| 입력 (Input from) | 시스템 요구사항 명세서 (system-requirements-spec.md)      |
+| 입력 (Input from) | FMEA 위험 통제 조치 (risk-table-fmea.md)                  |
+| 출력 (Input for)  | SW 아키텍처 설계서 (software-architecture-description.md) |
+| 출력 (Input for)  | 시스템 테스트 계획서 (software-system-test-plan.md)       |
+
+---
+
+## 7. 변경 이력 (Revision History)
+
+| 버전 | 날짜   | 작성자   | 변경 내용 |
+| ---- | ------ | -------- | --------- |
+| 0.1  | {DATE} | {AUTHOR} | 초안 작성 |
+
+---
+
+> Template based on IEC 62304:2006/AMD1:2015 Clausee 5.2, IEC 81001-5-1, MDR 2017/745 Annex I

package/vendor/dev-docs-templates/templates/mdr_docs/EA/soup-list.md

@@ -0,0 +1,82 @@
+# SOUP List (Software of Unknown Provenance)
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.8.1.2 기반 SOUP 목록입니다. EA 단계에서 초안 작성 후 매 Sprint 업데이트합니다.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - SW 아키텍처 설계서(software-architecture-description.md): SOUP 격리 전략 확인
+  - 프로젝트 requirements.txt / package.json: 실제 사용 라이브러리 목록 확인
+
+작성 지침:
+1. SOUP ID 체계: SOUP-{N:3d} (예: SOUP-001)
+2. 프로젝트에서 실제 사용하는 모든 서드파티 라이브러리/프레임워크를 포함하세요
+   (직접 의존성 + 주요 간접 의존성)
+3. 위험 등급 판단 기준:
+   - Low: 고장 시 환자 위해 없음 (로깅, UI 유틸리티 등)
+   - Medium: 고장 시 가역적 위해 가능 (데이터 처리 라이브러리 등)
+   - High: 고장 시 비가역적 위해 가능 (인증, 암호화, 진단 알고리즘 라이브러리 등)
+4. CVE 취약점은 최소 6개월마다 검토하고 "Last verified at" 날짜를 업데이트하세요
+   (SOP Integrated Software Development 참조)
+5. IEC 81001-5-1 관점: 보안 관련 SOUP(인증, 암호화 등)는 Known Anomalies를 반드시 확인하세요
+
+SOUP 추가 체크리스트 (신규 추가 시):
+  [ ] 버전 고정 (pinned version) 여부 확인
+  [ ] CVE 데이터베이스 조회 (https://nvd.nist.gov)
+  [ ] 라이선스 호환성 확인
+  [ ] SBOM(Software Bill of Materials) 업데이트
+  [ ] SAD의 SOUP 격리 전략 섹션에 반영
+-->
+
+
+> The 62304 requires you to document your SOUP, which is short for Software of Unknown Provenance. In human
+> language, those are the third-party libraries you're using in your code, typically in your
+> `requirements.txt` or `Gemfile`.
+
+| Classes | IEC 62304:2006 Section                          | Document Section |
+| ------- | ----------------------------------------------- | ---------------- |
+| B, C    | 5.3.3 (Functional and Performance Requirements) | 2                |
+| B, C    | 5.3.4 (Hardware and Software Requirements)      | 2                |
+| B, C    | 7.1.2 (Hazardous Situations)                    | 2                |
+| B, C    | 7.1.3 (SOUP Anomaly Lists)                      | 2                |
+| A, B, C | 8.1.2 (Identify SOUP)                           | 2                |
+
+## 1 Risk Level Definitions
+
+> The 62304 requires you to assess risks associated with SOUP. The simplest way to do this is to classify each
+> SOUP as a certain risk level. Unless you're developing software which shoots radiation at patients, it's
+> likely that your SOUP risk levels remain "low" or "medium".
+
+| Risk Level | Definition                                                 |
+| ---------- | ---------------------------------------------------------- |
+| Low        | Malfunction in SOUP can't lead to patient harm.            |
+| Medium     | Malfunction in SOUP can lead to reversible patient harm.   |
+| High       | Malfunction in SOUP can lead to irreversible patient harm. |
+
+## 2 SOUP List
+
+> This is the actual SOUP list. For each third-party library you use, add an entry in the table below. The
+> idea is to only have one "global" SOUP list for your medical device even though the code may actually live
+> in multiple repositories. That's what the "software system" column is for; you could also mention your (git)
+> repository there.
+
+> When specifying requirements, the 62304 requires you to mention functional, performance, hard- and software
+> requirements. However, you may not have to re-state certain requirements if they apply to all SOUP,
+> e.g., "runs on Linux". So prefer to keep the requirements simple, in a way in which you would communicate them
+> to colleagues on your development team when answering the question "why did we import this library?".
+
+> As with all templates: It's more about the content (i.e., the columns you see below) than the tool (filling
+> this out in Google sheets / markdown / wherever). Nobody says that you have to maintain this as a Google
+> sheet. If you can find a way to integrate this in your workflow in a better way, e.g., in a markdown file in
+> your git repository, go for it! Just keep in mind that you need to be able to export it to send it to
+> auditors.
+
+| ID  | Software System | Package Name | Programming Language | Version | Website                                          | Last verified at | Risk Level | Requirements               | Verification Reasoning                                                      |
+| --- | --------------- | ------------ | -------------------- | ------- | ------------------------------------------------ | ---------------- | ---------- | -------------------------- | --------------------------------------------------------------------------- |
+| 1   | Mobile App      | react-native | JavaScript           | 0.61    | [Link](https://facebook.github.io/react-native/) | 23.10.2020       | Low        | * Runs JS on Android / iOS | Commonly used, maintained by a large organisation, sufficient test coverage |
+
+---
+
+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/EA/usability-evaluation-plan.md

@@ -0,0 +1,103 @@
+# Usability Evaluation Plan
+
+The Usability Evaluation Plan describes the Usability Evaluation activities and their required resources which
+will be performed for the device.
+
+## Mapping of Standard Requirements to Document Sections
+
+| IEC 62366-1:2015 Section | Title                                         | Document Section |
+|--------------------------|-----------------------------------------------|------------------|
+| 4.2                      | Usability Engineering File                    | (all)            |
+| 4.3                      | Tailoring of the Usability Engineering effort | (all)            |
+
+## 1. Relevant Processes
+
+Usability Engineering and Evaluation activities are defined in the **SOP Integrated Software Development**.
+
+## 2. Related Documents
+
+ * List of Hazard-Related Use Scenarios
+ * Usability Evaluation Report
+
+## 3. Roles
+
+| Title                                           | Name(s) |
+|-------------------------------------------------|---------|
+| Head of Usability                               |         |
+| Context / Subject Matter Expert, e.g., physician |         |
+
+## 4. Formative Usability Evaluation
+
+### 4.1 Methods
+
+Formative Usability Evaluation is performed with the following methods:
+
+ * **Presentation of mockups or prototypes to subject matter experts:** E.g., by demonstrating the
+   functionality in an in-person or remote screen sharing session.
+ * **Feedback sessions with UX/UI experts:** Showing concepts, designs, mockups or prototypes to internal or
+   external UX/UI experts with the goal of gathering feedback on potential usability problems and
+   improvements.
+ * **User Tests:** Letting users of the intended target user group use the device based on a Usability
+   Evaluation protocol, observing them and documenting potential Usability problems. This is essentially the
+   same methods as the Summative Usability Evaluation, with the only difference being that it's being done on
+   a development (non-final, non-release) version of the device with the goal of gathering knowledge for
+   improving the final device.
+
+### 4.2 Planning (Overview)
+
+| Date       | Description                                                                               |
+|------------|-------------------------------------------------------------------------------------------|
+| 01.01.2021 | *Formative Evaluation 1*<br>(Description of methods incl. environment, participants etc.) |
+
+## 5 Summative Usability Evaluation
+
+### 5.1 Method
+
+Summative Usability Evaluation is conducted by performing User Tests.
+
+User Tests must comply with the following requirements:
+
+ * The user profile is the one specified in the Device Description.
+ * All Hazard-Related Use Scenarios must be covered by test cases (see IEC 62366, para. 5.7.3 / 5.9).
+ * Sufficient stakeholder requirements / user needs must be covered by test cases to ensure that the product
+   meets its intended use (see ISO 13485, para. 7.3.7)
+ * At least five test participants.
+ * The Usability Test Protocol must be filled out which descriptions of each use scenario and
+   instructions. It is also used to document the observations and discovered hazards.
+
+The following requirements are optional:
+
+ * Usability Tests are recorded, e.g., video/audio (either in-person or remotely) and screen recording (of
+   phone / desktop computer)
+
+Results of Summative Usability Evaluation are summarized in the Usability Evaluation Report, most importantly:
+
+ * Could all tasks in the Usability Test Protocol be achieved?
+   * If not, why?
+ * Which Use Errors occurred and could they lead to Hazardous Situations? --> Risk analysis of use errors
+
+## 5.2 Planning (Setting)
+
+#### Participants
+
+#### Setting
+
+#### Methods and Analysis
+
+> Describe whether it's done in person or remotely and how you will document the results (have a protocol at
+> the minimum), optionally also record the sessions.
+>
+> Also, describe how you plan to analyse the data.
+
+## 5.3 Planning (Overview)
+
+| Date       | Description                                                                               |
+|------------|-------------------------------------------------------------------------------------------|
+| 02.01.2021 | *Summative Evaluation 1*<br>(Description of methods incl. environment, participants etc.) |
+
+---
+
+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/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.