@neobiotechlabs/neobiotech-dev-agent 0.1.7

package/vendor/dev-docs-templates/templates/mdr_docs/PA/mdr-classification-document.md

@@ -0,0 +1,114 @@
+# MDR Classification Document
+
+## Mapping of Requirements
+
+| Medical Device Regulation (MDR) | Document Section |
+| ------------------------------- | ---------------- |
+| Annex VIII | (All) |
+
+**Related documents:**
+
+* Intended Use
+* SOP Product Certification and Registration
+
+## Summary
+
+| Product:        | (enter content) |
+|-----------------|-----------------|
+| Version:        | (enter content) |
+| Classification: | (enter content) |
+| Rule:           | (enter content) |
+
+Rationale for the qualification of the product as a medical device (MDR Annex II, para. 1.1.e):
+See Intended Use Statement
+
+## Chapter 1: Applicable Definitions
+
+> You will need to carefully check and fill out all rows below. Some rows are pre-filled for applicability
+> under the assumption of a stand-alone software medical device. However, this is quite an essential document
+> and you're better off checking twice.
+
+**1. Duration of Use**
+
+| Term       | Definition                                                      | Applicable |
+|------------|-----------------------------------------------------------------|------------|
+| Transient  | Normally intended for continuous use for less than 60 minutes.  |            |
+| Short term | Normally intended for continuous use for not more than 30 days. |            |
+| Long term  | Normally intended for continuous use for more than 30 days.     |            |
+|            |                                                                 |            |
+
+**2. Invasive and Active Devices**
+
+| Definition | Applicable |
+| ---------- | ---------- |
+| **2.1 Body orifice** means any natural opening in the body, as well as the external surface of the eyeball, or any permanent artificial opening, such as a stoma. | No |
+| **2.2 Surgically invasive device** means:<br>(a) an invasive device which penetrates inside the body through the surface of the body, including through mucous membranes of body orifices with the aid or in the context of a surgical operation; and<br>(b) a device which produces penetration other than through a body orifice. | No |
+| **2.3 Reusable surgical instrument** means an instrument intended for surgical use in cutting, drilling, sawing, scratching, scraping, clamping, retracting, clipping or similar procedures, without a connection to an active device and which is intended by the manufacturer to be reused after appropriate procedures such as cleaning, disinfection and sterilization have been carried out. | No |
+| **2.4 Active therapeutic device** means any active device used, whether alone or in combination with other devices, to<br>support, modify, replace or restore biological functions or structures with a view to treatment or alleviation of an<br>illness, injury or disability. |  |
+| **2.5 Active device intended for diagnosis and monitoring** means any active device used, whether alone or in combination with other devices, to supply information for detecting, diagnosing, monitoring or treating physio logical conditions, states of health, illnesses or congenital deformities. |  |
+| **2.6 Central circulatory system** means the following blood vessels:<br>arteriae pulmonales, aorta ascendens, arcus aortae, aorta descendens to the bifurcatio aortae, arteriae coronariae, arteria carotis communis, arteria carotis externa, arteria carotis interna, arteriae cerebrales, truncus brachiocephalicus, venae cordis, venae pulmonales, vena cava superior and vena cava inferior. |  |
+| **2.7 Central nervous system** means the brain, meninges and spinal cord. |  |
+| **2.8 Injured skin or mucous membrane** means an area of skin or a mucous membrane presenting a pathological<br>change or change following disease or a wound. |  |
+
+## Chapter 2: Implementing Rules
+
+| Rules | Applicable |
+| ----- | ---------- |
+| **3.1** Application of the classification rules shall be governed by the intended purpose of the devices. | Yes |
+| **3.2** If the device in question is intended to be used in combination with another device, the classification rules shall apply separately to each of the devices. Accessories for a medical device and for a product listed in Annex XVI MDR shall be classified in their own right separately from the device with which they are used. |  |
+| **3.3** Software, which drives a device or influences the use of a device, shall fall within the same class as the device.<br>If the software is independent of any other device, it shall be classified in its own right. |  |
+| **3.4** If the device is not intended to be used solely or principally in a specific part of the body, it shall be considered and classified on the basis of the most critical specified use. |  |
+| **3.5** If several rules, or if, within the same rule, several sub-rules, apply to the same device based on the device's intended purpose, the strictest rule and sub-rule resulting in the higher classification shall apply. |  |
+| **3.6** In calculating the duration referred to in Section 1, continuous use shall mean:<br>(a) the entire duration of use of the same device without regard to temporary interruption of use during a procedure or temporary removal for purposes such as cleaning or disinfection of the device. Whether the interruption of use or the removal is temporary shall be established in relation to the duration of the use prior to and after the period when the use is interrupted or the device removed; and<br>(b) the accumulated use of a device that is intended by the manufacturer to be replaced immediately with another of the same type. |  |
+| **3.7** A device is considered to allow direct diagnosis when it provides the diagnosis of the disease or condition in question by itself or when it provides decisive information for the diagnosis. |  |
+
+## Chapter 3: Classification Rules
+
+**4.) Non-Invasive Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 1***<br>All non-invasive devices are classified as class I, unless one of the rules set out hereinafter applies. |  |
+| ***Rule 2***<br>All non-invasive devices intended for channelling or storing blood, body liquids, cells or tissues, liquids or gases for the purpose of eventual infusion, administration or introduction into the body are classified as class IIa:<br>— if they may be connected to a class IIa, class IIb or class III active device; or<br>— if they are intended for use for channelling or storing blood or other body liquids or for storing organs, parts<br>of organs or body cells and tissues, except for blood bags; blood bags are classified as class IIb.<br>In all other cases, such devices are classified as class I. | No |
+| ***Rule 3***<br>All non-invasive devices intended for modifying the biological or chemical composition of human tissues or cells, blood, other body liquids or other liquids intended for implantation or administration into the body are classified as class IIb, unless the treatment for which the device is used consists of filtration, centrifugation or exchanges of gas, heat, in which case they are classified as class IIa.<br><br>All non-invasive devices consisting of a substance or a mixture of substances intended to be used in vitro in direct<br>contact with human cells, tissues or organs taken from the human body or used in vitro with human embryos<br>before their implantation or administration into the body are classified as class III. | No |
+| ***Rule 4***<br>All non-invasive devices which come into contact with injured skin or mucous membrane are classified as:<br>— class I if they are intended to be used as a mechanical barrier, for compression or for absorption of exudates;<br>— class IIb if they are intended to be used principally for injuries to skin which have breached the dermis or<br>mucous membrane and can only heal by secondary intent;<br>— class IIa if they are principally intended to manage the micro-environment of injured skin or mucous membrane; and<br>— class IIa in all other cases.<br><br>This rule applies also to the invasive devices that come into contact with injured mucous membrane. | No |
+
+**5.) Invasive Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 5***<br>All invasive devices with respect to body orifices, other than surgically invasive devices, which are not intended for connection to an active device or which are intended for connection to a class I active device are classified as:<br>— class I if they are intended for transient use;<br>— class IIa if they are intended for short-term use, except if they are used in the oral cavity as far as the pharynx, in an ear canal up to the ear drum or in the nasal cavity, in which case they are classified as class I; and<br>— class IIb if they are intended for long-term use, except if they are used in the oral cavity as far as the pharynx, in an ear canal up to the ear drum or in the nasal cavity and are not liable to be absorbed by the mucous membrane, in which case they are classified as class IIa.<br><br>All invasive devices with respect to body orifices, other than surgically invasive devices, intended for connection<br>to a class IIa, class IIb or class III active device, are classified as class IIa. | No |
+| ***Rule 6***<br>All surgically invasive devices intended for transient use are classified as class IIa unless they:<br>— are intended specifically to control, diagnose, monitor or correct a defect of the heart or of the central circulatory system through direct contact with those parts of the body, in which case they are classified as class III;<br>— are reusable surgical instruments, in which case they are classified as class I;<br>— are intended specifically for use in direct contact with the heart or central circulatory system or the central nervous system, in which case they are classified as class III;<br>— are intended to supply energy in the form of ionising radiation in which case they are classified as class IIb;<br>— have a biological effect or are wholly or mainly absorbed in which case they are classified as class IIb; or<br>— are intended to administer medicinal products by means of a delivery system, if such administration of a medicinal product is done in a manner that is potentially hazardous taking account of the mode of application, in which case they are classified as class IIb. | No |
+| ***Rule 7***<br>All surgically invasive devices intended for short-term use are classified as class IIa unless they:<br>— are intended specifically to control, diagnose, monitor or correct a defect of the heart or of the central circulatory system through direct contact with those parts of the body, in which case they are classified as class III;<br>— are intended specifically for use in direct contact with the heart or central circulatory system or the central nervous system, in which case they are classified as class III;<br>— are intended to supply energy in the form of ionizing radiation in which case they are classified as class IIb;<br>— have a biological effect or are wholly or mainly absorbed in which case they are classified as class III;<br>— are intended to undergo chemical change in the body in which case they are classified as class IIb, except if the devices are placed in the teeth; or<br>— are intended to administer medicines, in which case they are classified as class IIb. | No |
+| ***Rule 8***<br>All implantable devices and long-term surgically invasive devices are classified as class IIb unless they:<br>— are intended to be placed in the teeth, in which case they are classified as class IIa;<br>— are intended to be used in direct contact with the heart, the central circulatory system or the central nervous system, in which case they are classified as class III;<br>— have a biological effect or are wholly or mainly absorbed, in which case they are classified as class III;<br>— are intended to undergo chemical change in the body in which case they are classified as class III, except if the devices are placed in the teeth;<br>— are intended to administer medicinal products, in which case they are classified as class III;<br>— are active implantable devices or their accessories, in which cases they are classified as class III;<br>— are breast implants or surgical meshes, in which cases they are classified as class III;<br>— are total or partial joint replacements, in which case they are classified as class III, with the exception of ancillary components such as screws, wedges, plates and instruments; or<br>— are spinal disc replacement implants or are implantable devices that come into contact with the spinal column, in which case they are classified as class III with the exception of components such as screws, wedges, plates and instruments. | No |
+
+**6.) Active Devices**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 9***<br>All active therapeutic devices intended to administer or exchange energy are classified as class IIa unless their characteristics are such that they may administer energy to or exchange energy with the human body in a potentially hazardous way, taking account of the nature, the density and site of application of the energy, in which case they are classified as class IIb.<br><br>All active devices intended to control or monitor the performance of active therapeutic class IIb devices, or intended directly to influence the performance of such devices are classified as class IIb.<br><br>All active devices intended to emit ionizing radiation for therapeutic purposes, including devices which control or monitor such devices, or which directly influence their performance, are classified as class IIb.<br><br>All active devices that are intended for controlling, monitoring or directly influencing the performance of active implantable devices are classified as class III. |  |
+| ***Rule 10***<br>Active devices intended for diagnosis and monitoring are classified as class IIa:<br>— if they are intended to supply energy which will be absorbed by the human body, except for devices intended to illuminate the patient's body, in the visible spectrum, in which case they are classified as class I;<br>— if they are intended to image in vivo distribution of radiopharmaceuticals; or<br>— if they are intended to allow direct diagnosis or monitoring of vital physiological processes, unless they are specifically intended for monitoring of vital physiological parameters and the nature of variations of those parameters is such that it could result in immediate danger to the patient, for instance variations in cardiac performance, respiration, activity of the central nervous system, or they are intended for diagnosis in clinical situations where the patient is in immediate danger, in which cases they are classified as class IIb.<br><br>Active devices intended to emit ionizing radiation and intended for diagnostic or therapeutic radiology, including interventional radiology devices and devices which control or monitor such devices, or which directly influence their performance, are classified as class IIb. |  |
+| ***Rule 11***<br>Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:<br>— death or an irreversible deterioration of a person's state of health, in which case it is in class III; or<br>— a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb.<br><br>Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I. | Yes |
+| ***Rule 12***<br>All active devices intended to administer and/or remove medicinal products, body liquids or other substances to or from the body are classified as class IIa, unless this is done in a manner that is potentially hazardous, taking account of the nature of the substances involved, of the part of the body concerned and of the mode of application in which case they are classified as class IIb. |  |
+| ***Rule 13***<br>All other active devices are classified as class I. |  |
+
+**7.) Special Rules**
+
+| Rules | Applicable |
+| ----- | ---------- |
+| ***Rule 14***<br>All devices incorporating, as an integral part, a substance which, if used separately, can be considered to be a medicinal product, as defined in point 2 of Article 1 of Directive 2001/83/EC, including a medicinal product derived from human blood or human plasma, as defined in point 10 of Article 1 of that Directive, and that has an action ancillary to that of the devices, are classified as class III. | No |
+| ***Rule 15***<br>All devices used for contraception or prevention of the transmission of sexually transmitted diseases are classified as class IIb, unless they are implantable or long term invasive devices, in which case they are classified as class III. | No |
+| ***Rule 16***<br>All devices intended specifically to be used for disinfecting, cleaning, rinsing or, where appropriate, hydrating contact lenses are classified as class IIb.<br><br>All devices intended specifically to be used for disinfecting or sterilising medical devices are classified as class IIa, unless they are disinfecting solutions or washer-disinfectors intended specifically to be used for disinfecting invasive devices, as the end point of processing, in which case they are classified as class IIb.<br><br>This rule does not apply to devices that are intended to clean devices other than contact lenses by means of physical action only. | No |
+| ***Rule 17***<br>Devices specifically intended for recording of diagnostic images generated by X-ray radiation are classified as class IIa. | No |
+| ***Rule 18***<br>All devices manufactured utilizing tissues or cells of human or animal origin, or their derivatives, which are non-viable or rendered non-viable, are classified as class III, unless such devices are manufactured utilizing tissues or cells of animal origin, or their derivatives, which are non-viable or rendered non-viable and are devices intended to come into contact with intact skin only. | No |
+| ***Rule 19***<br>All devices incorporating or consisting of nanomaterial are classified as:<br>— class III if they present a high or medium potential for internal exposure;<br>— class IIb if they present a low potential for internal exposure; and<br>— class IIa if they present a negligible potential for internal exposure. | No |
+| ***Rule 20***<br>All invasive devices with respect to body orifices, other than surgically invasive devices, which are intended to administer medicinal products by inhalation are classified as class IIa, unless their mode of action has an essential impact on the efficacy and safety of the administered medicinal product or they are intended to treat life-threatening conditions, in which case they are classified as class IIb. | No |
+| ***Rule 21***<br>Devices that are composed of substances or of combinations of substances that are intended to be introduced into the human body via a body orifice or applied to the skin and that are absorbed by or locally dispersed in the human body are classified as:<br>— class III if they, or their products of metabolism, are systemically absorbed by the human body in order to achieve the intended purpose;<br>— class III if they achieve their intended purpose in the stomach or lower gastrointestinal tract and they, or their products of metabolism, are systemically absorbed by the human body;<br>— class IIa if they are applied to the skin or if they are applied in the nasal or oral cavity as far as the pharynx, and achieve their intended purpose on those cavities; and<br>— class IIb in all other cases. | No |
+| ***Rule 22***<br>Active therapeutic devices with an integrated or incorporated diagnostic function which significantly determines the patient management by the device, such as closed loop systems or automated external defibrillators, are classified as class III. |  |
+
+---
+
+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/PA/risk-management-plan.md

@@ -0,0 +1,198 @@
+# Risk Management Plan
+
+<!-- AI AGENT 작성 지침
+이 문서는 ISO 14971:2019 기반 위험 관리 계획서입니다. PA 단계에서 작성하는 핵심 산출물입니다.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - 사용 목적 정의서(intended-use.md): 의도된 사용자, 사용 환경, 의료 목적 확인
+
+작성 지침:
+1. 제품명과 버전을 문서 상단에 명시하세요
+2. 1.2.1 사용량 추정은 실제 제품의 예상 사용자 수와 수명을 기반으로 작성하세요
+   - 예: 제품 수명 3년, 일일 100회 사용 -> 총 109,575회 사용
+3. 1.2.2 중증도 등급(S1~S4)은 실제 제품에서 발생 가능한 위해 예시로 변경하세요
+   - 진단 보조 SW의 경우: 오진으로 인한 불필요한 시술, 치료 지연 등
+4. 1.2.3 확률 등급(P1~P5)의 "Estimated Maximum Event Count"를 실제 사용량 계산 결과로 업데이트하세요
+5. 1.2.4 위험 허용 매트릭스는 제품의 의료적 이득-위험 균형을 반영하여 결정하세요
+6. 담당자(Roles) 섹션에 실제 담당자 이름과 역할을 기재하세요
+
+위험 관리 계획서 완성 체크리스트:
+  [ ] 제품명/버전 명시
+  [ ] 위험 관리자(Risk Manager) 지정
+  [ ] 사용량 추정 수치 입력
+  [ ] 중증도 정의가 제품 특성에 맞게 수정됨
+  [ ] 위험 허용 매트릭스 경영진 승인 완료
+  [ ] SOP Integrated Software Development 참조 확인
+-->
+
+
+The Risk Management Plan contains the risk policy and defines the criteria for risk acceptance. It also
+references relevant processes and activities which will be conducted for product-specific risk management as
+part of the integrated software development process (SOP Integrated Software Development).
+
+## Mapping of Standard Requirements to Document Sections
+
+| ISO 14971:2019 Section | Document Section                                |
+| ---------------------- | ----------------------------------------------- |
+| 4.1                    | 1                                               |
+| 4.2                    | 1.2, 3                                          |
+| 4.3                    | (Records of competence are kept as Part of QMS) |
+| 4.4                    | (all)                                           |
+| 4.5                    | (all)                                           |
+| 5.1                    | 1.1                                             |
+| 7.2                    | 1.3                                             |
+| 10.1                   | 1.4                                             |
+
+## 1. Relevant Processes
+
+### 1.1 Risk Management Process and Activities
+
+Risk Management Activities are integrated in the software development lifecycle as described in SOP Integrated
+Software Development. The scope of this risk management plan therefore covers the entire software device lifecycle.
+
+When creating a first-time risk analysis for a product, Annex C of ISO 14971 should be reviewed for applicable examples.
+
+### 1.2 Risk Policy and Risk Acceptability
+
+The following policy establishes criteria for risk acceptability following ISO 14971:2019 and ISO/TR
+24971:2020. It applies to all people and activities involved in the design, development and distribution
+process of the medical device, and intends to ensure highest levels of medical device safety consistent with
+stakeholder expectations.
+
+The manufacturer defines framework criteria for risk acceptability in the form of estimated usage, severity of
+harm and probability of occurrence. The criteria are initially defined as part of the early software development process and reviewed during each post-market surveillance cycle.
+
+Estimated usage, categories of severity / probability and risk matrix acceptance are defined based on
+applicable regulatory requirements, relevant international norms and standards, as well as the generally
+acknowledged state of the art (e.g. accepted results of scientific research, reports published by authorities,
+established industry best practices).
+
+Acceptability for individual risks always must be established based on both, the estimated severity and the
+estimated probability of a risk. The risk is deemed acceptable based on a combination of both, following the
+risk matrix defined in para. 1.2.4.
+
+All identified risks must be reduced as far as possible (AFAP) without adversely affecting the
+benefit-risk-ratio. Risk control measures implemented to reduce the risks must be chosen in the following
+order:
+
+1. Inherent safety by design
+2. Protective measures
+3. Information for safety
+
+Users of the device must be informed about any remaining residual risks.
+
+Acceptability of the overall residual risk is established as part of the clinical evaluation process by
+weighing benefits from intended use against the overall residual risk. Benefits may be described by their
+magnitude or extent, the probability of experience within the intended patient population, the duration and
+frequency of the benefit. For example, the manufacturer may compare the device to similar medical devices
+available on the market: residual risks can be compared individually to corresponding risks of the similar
+device, considering differences in intended use. The overall evaluation of the benefit-risk-ratio should take
+into account knowledge of the intended medical indication, the generally acknowledged state of the art in
+technology and medicine, and the availability of alternative medical devices or treatments.
+
+#### 1.2.1 Estimates for Usage
+
+> Define estimates for how much you think your device is going to be used in the market.
+
+| Usage             | Values                                                                                                             |
+| ----------------- | ------------------------------------------------------------------------------------------------------------------ |
+| Product life span | Enter number of years you expect the device to be in the market (from design conceptualization to decommissioning) |
+| Users             | Enter number of estimated users here                                                                               |
+| Usages / user     | Enter number of estimated times the device is used per user                                                        |
+| Total usages      | Do the math!                                                                                                       |
+
+The software's lifetime is established to be [for example: three years]. This is what is expected to be the
+maximum time until the implementation of a significant change, by which the manufacturer is able to react to
+the relevant changes to the software device environment, such as SOUP changes, cybersecurity innovations, or
+the evolving technological or medical state of the art.
+
+Estimated product lifetime may not align with the planned PMS / PMCF surveillance periods, as continuous risk
+management involves continuous updates of the risk management file in order to account for new information in
+a timely manner.
+
+#### 1.2.2 Severity of Harm
+
+> Define what can go wrong with your product here. Make the examples specific - chances are, your product
+> can't cause skin lacerations. In all likelihood it also doesn't cause death. So, feel free to remove
+> severity rows here. But most importantly, customize the definitions and examples so that they resemble the
+> harms in your product.
+
+| Severity         | Definition and Examples                                                                                   |
+| ---------------- | --------------------------------------------------------------------------------------------------------- |
+| S1: Negligible   | Minor, reversible damage, e.g. superficial skin irritation, delay of non-critical treatment               |
+| S2: Marginal     | Minor, reversible damage with required medical intervention, e.g. skin laceration requiring stitches      |
+| S3: Critical     | Major, irreversible damage with required medical intervention, e.g. irreversible deterioration of disease |
+| S4: Catastrophic | Death                                                                                                     |
+
+#### 1.2.3 Probability of Occurrence
+
+> Define your probabilities. You can probably just use these definitions. The idea is that each probability
+> row is 10^2 apart from adjacent ones.
+
+> Also, change the "Estimated Maximum Event Count". That's the usage number you estimate for your (not yet
+> released product) during its entire lifecycle (which you need to define). So, if you assume that your
+> product will be on the market for 4 years and that it'll be used 100 times per day, that results in 146.100
+> usages (100 usages/day * 365.25 days/year * 4 years). The numbers in the lower columns of "Estimated Maximum
+> Event Count" are simply the total usage number multiplied by the upper limit probability of the same row,
+> e.g. you want to know "how often can probability P3 occur if the product is being used 100 times per day?"
+
+| Probability     | Upper Limit | Lower Limit | Estimated Maximum Event Count |
+| --------------- | ----------- | ----------- | ----------------------------- |
+| P5: Certain     | 1           | 10^-2       | 1000000 *(change this*)       |
+| P4: Likely      | 10^-2       | 10^-4       | 10000                         |
+| P3: Unlikely    | 10^-4       | 10^-6       | 100                           |
+| P2: Rare        | 10^-6       | 10^-8       | 1                             |
+| P1: Unthinkable | 10^-8       | 0           | 0                             |
+
+#### 1.2.4 Risk Acceptance Matrix
+
+> The most important part. You assess each severity-probability combination whether it's acceptable for you as
+> a company. There are no definitive rules on what's deemed acceptable. It depends on your company's risk
+> policy and, more importantly, the benefits of your product which you show in your clinical evaluation. So,
+> for example, if your product saves 10 lives per day, it might be acceptable to cause one death per day. If
+> your product doesn't save any lives, it might not be acceptable to cause any deaths. You get the idea, I
+> hope.
+
+| Probability     | S1: Negligible | S2: Marginal     | S3: Critical     | S4: Catastrophic | Estimated Maximum Event Count |
+| --------------- | -------------- | ---------------- | ---------------- | ---------------- | ----------------------------- |
+| P5: Certain     | acceptable     | **unacceptable** | **unacceptable** | **unacceptable** | 1000000                       |
+| P4: Likely      | acceptable     | **unacceptable** | **unacceptable** | **unacceptable** | 10000                         |
+| P3: Unlikely    | acceptable     | acceptable       | **unacceptable** | **unacceptable** | 100                           |
+| P2: Rare        | acceptable     | acceptable       | acceptable       | **unacceptable** | 1                             |
+| P1: Unthinkable | acceptable     | acceptable       | acceptable       | acceptable       | 0                             |
+
+### 1.3 Verification of Risk Control Measures
+
+Risk Control Measures are verified as described in the software development lifecycle as described in SOP
+Integrated Software Development.
+
+### 1.4 Assessment of the overall residual risk
+
+After determination of the Risk Control Measures any risk that could arise from the combination of the
+individual risks or mitigating measures is assessed. For this purpose, the probability and severity of the
+possible residual risk are estimated and evaluated using the existing risk matrix.
+
+### 1.5 Collection and Review of Post-Production Information
+
+Review and collection of Post-Production information is described in SOP Post-Market Surveillance.
+
+## 2. Related Documents
+
+ * SOP Integrated Software Development
+ * Risk Acceptance Matrix
+ * Risk Table
+ * Risk Management Report
+
+## 3. Roles
+
+| Title                                           | Name(s) |
+| ----------------------------------------------- | ------- |
+| Risk Manager                                    |         |
+| Context / Subject Matter Expert, e.g. physician |         |
+
+---
+
+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/PA/software-development-maintenance-plan.md

@@ -0,0 +1,225 @@
+# Software Development and Maintenance Plan
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.5.1 기반 SW 개발 및 유지보수 계획서입니다. PA 단계 핵심 산출물입니다.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - 시스템 요구사항 명세서(system-requirements-spec.md): 팀 구성, 타겟 환경 확인
+  - 사용 목적 정의서(intended-use.md): 제품명, SW 안전 등급 확인
+
+작성 지침:
+1. Section 2.2 (SW 안전 등급): IEC 62304 Cl.4.3 기준으로 Class A/B/C를 결정하고 근거를 기술하세요
+2. Section 3 (Design Phases): 우리 Gate 프로세스에 맞게 PA/EA/ER/CA로 업데이트하세요
+   - PA: 기획 및 계획 -> 개발 시작 전 승인
+   - EA: 요구사항 및 설계 -> 코딩 시작 전 승인
+   - ER: 구현 및 검증 -> Sprint 반복 (Sprint No, 완료 일자 기입)
+   - CA: 최종 릴리스 -> 검증 완료 후 승인
+3. Section 5 (Configuration Management): 반드시 상세히 작성하세요 (형상관리 계획 역할)
+   - Git 브랜치 전략 (feature/release/main 등)
+   - 버전 체계 (semantic versioning: MAJOR.MINOR.PATCH)
+   - 변경 통제 절차 (Change Evaluation List 참조)
+4. 사이버보안 계획은 별도 파일 없이 이 SDP 내에 챕터로 작성하세요:
+   - 보안 설계 원칙 (Security by Design)
+   - 취약점 모니터링 주기 (CVE 검토)
+   - 보안 사고 대응 절차
+5. Section 2.1 팀 구성에 실제 인원을 기재하고 역할을 구체화하세요
+
+완성 체크리스트:
+  [ ] 제품명 및 SW 안전 등급 명시
+  [ ] Design Phases에 PA/EA/ER/CA Gate 반영
+  [ ] Section 5 형상관리 상세 기술 (Git 브랜치, 버전 체계)
+  [ ] 사이버보안 챕터 추가 (IEC 81001-5-1)
+  [ ] 담당자 역할(R&R) 기재
+-->
+
+
+This document summarizes development and maintenance activities.
+
+## Mapping of Standard Requirements to Document Sections
+
+| ISO 13485:2016 Section                | Document Section |
+| ------------------------------------- | ---------------- |
+| 7.3.2 Design and Development Planning | 1, 2, 3, 7       |
+
+| Classes | IEC 62304:2006 Section                                                     | Document Section |
+| ------- | -------------------------------------------------------------------------- | ---------------- |
+| A, B, C | 4.4.2 Risk Management Activities                                           | 1                |
+| A, B, C | 5.1.1 a) (Processes)                                                       | 1                |
+| A, B, C | 5.1.1 b) (Deliverables)                                                    | 1                |
+| A, B, C | 5.1.1 c) (Traceability)                                                    | 1                |
+| A, B, C | 5.1.1 d) (Configuration and Change Management)                             | 1, 5             |
+| A, B, C | 5.1.1 e) (Problem Resolution)                                              | 1                |
+| A, B, C | 5.1.2 Keep Software Development Plan Updated                               | 1                |
+| A, B, C | 5.1.3 Software Development Plan Reference to System Design and Development | 2                |
+| C       | 5.1.4 Software Development Standards, Methods and Tools Planning           |                  |
+| B, C    | 5.1.5 Software Integration and Integration Test Planning                   | 3, 8             |
+| A, B, C | 5.1.6 Software Verification Planning                                       | 7                |
+| A, B, C | 5.1.7 Software Risk Management Planning                                    | 1                |
+| A, B, C | 5.1.8 Documentation Planning                                               | 6                |
+| A, B, C | 5.1.9 Software Configuration Management Planning                           | 5                |
+| B, C    | 5.1.10 Supporting Items to be Controlled                                   | 5                |
+| B, C    | 5.1.11 Software Configuration Item Control Before Verification             | 5                |
+| B, C    | 5.1.12 Identification and Avoidance of Common Software Defects             | 4                |
+| A, B, C | 6.1 Software Maintenance Plan.                                             | 10               |
+
+## 1 Relevant Processes and Documents
+
+Please see the relevant processes for the following activities:
+
+ * Risk management activities incl. SOUP risks: SOP Integrated Software Development
+ * Problem resolution: SOP Problem Resolution
+ * Software development incl. deliverables, traceability, regular update of software development plan: SOP
+   Integrated Software Development
+ * Change management: SOP Change Management
+ * SOUP List
+ * Usability engineering activities: SOP Integrated Software Development
+
+## 2. Required Resources
+
+### 2.1 Team
+
+| Role                | Count | Responsibilities                            |
+| ------------------- | ----- | ------------------------------------------- |
+| Head of Development | 1     | Prioritizing tasks and technical oversight  |
+| Frontend Developer  | 2     | Implementing Frontend Software Requirements |
+| Backend Developer   | 1     | Implementing Backend Software Requirements  |
+
+### 2.2 Software
+
+#### IEC 62304 Software Safety Classification
+
+The software safety classification for \[enter device name\] has been established as class \[XXXX\] per IEC 62304:2006/AMD1:2015 based on the decision-making process outlined in table 3 and in paragraph 4.3 of the norm. A malfunction of, or latent design flaw in the software device may lead to situations with unacceptable risks \[for example: false-positive and false-negative diagnosis, resulting in unnecessary interventions or missed necessary interventions\]. This excludes software safety class A. Serious injuries or death, however, can be ruled out because \[XXXX\]. Considering these risk control measures external to the software system, safety class C can be ruled out, resulting in class B.
+
+#### Measuring Function
+
+The \[enter device name\] does not include a measuring function, as described in EU Regulation 2017/45 and relevant regulatory guidance documents. The definition of MEDDEV 2.1-5 for measuring functions does not apply because \[XXX\].
+
+#### Combination With Other Products
+
+To achieve its intended purpose, the \[enter device name\] is intended to be used in combination with \[for example: MRI/CT scanners that produce imaging data\]. Specifications for compatible equipment are described in the List of Software Requirements as well as in the Instructions for Use. Relevant verification and validation tests will be added to the documentation.
+
+#### Product Lifetime
+
+The software's lifetime is established to be \[for example: three years\]. This is what is expected to be the maximum time until the implementation of a significant change, by which the manufacturer is able to react to the relevant changes to the software device environment, such as SOUP changes, cybersecurity innovations, or the evolving technological or medical state of the art.
+
+#### Programming Languages
+
+> List the languages you’ll be using, including compiler and language versions.
+
+| Name   | Version |
+| ------ | ------- |
+| Python | 3.8     |
+
+#### Development Software
+
+> List software used to support development, e.g., IDEs.
+
+| Name    | Version  |
+| ------- | -------- |
+| PyCharm | 2020.1.4 |
+
+### 2.3 System Requirement / Target Runtime
+
+> List your target runtime(s).
+
+| Name    | Version |
+| ------- | ------- |
+| CPython | 3.8     |
+
+> Specify system requirements, e.g., the minimum specifications of the server / compute instance you'll be
+> running your software on
+
+*Minimum system requirements:*
+
+ * *Server-grade dual-core CPU, e.g., Intel Xeon E3-1230 v5 or higher*
+ * *4 GB of RAM*
+ * *1 GBit/s up- and downlink*
+ * *20GB SSD storage*
+
+## 3 Design Phases
+
+> The 13485 requires you to specify "Design Phases". Here are some suggestions which you could use.
+
+| Title          | Estimated Completion Date | Description | Review method                   |
+| -------------- | ------------------------- | ----------- | ------------------------------- |
+| Specification  |                           |             | Software Requirements Checklist |
+| Implementation |                           |             | Code Reviews                    |
+| Testing        |                           |             | System Test                     |
+| Validation     |                           |             | Usability Evaluation            |
+| Release        |                           |             | Release Checklist               |
+
+## 4 Avoiding Common Software Defects Based on Selected Programming Technology
+
+> Discuss how your selected programming technology may introduce risks and how you plan to avoid them. With
+> modern, dynamically-typed languages, an obvious risk is that you encounter runtime exceptions. So you could
+> argue that your test coverage is great and compensates for that. You could also link to your risk analysis
+> here if you analyse those risks further.
+
+## 5 Configuration Management and Version Control
+
+> Describe which version control software you're using (probably git, like all human beings on this planet
+> right now, except enterprise developers). Also describe your branching model, i.e., how your developers
+> create branches during development, how you name them and how you merge them (pull requests? merge commits?
+> squash before?). Your code review will be described in the next section.
+>
+> Importantly, describe which things (code, build files, etc.) are put in version control. Describe how you
+> name versions and how you tag them. Your goal should be that you can retrieve an old version and build
+> it. Why? Something with a newer version may go wrong (harm patients) and you may need to roll back.
+
+*git is used as version control software. All source code and build files are committed to version control.*
+
+*When implementing software requirements, developers create a new branch starting at master. During
+development, developers may create intermediate commits on this development branch.*
+
+*When implementation is completed, a new merge commit to master is created.*
+
+***This is also the activity which constitutes integration of software units.***
+
+*For each release, the goal is to be able to uniquely identify it and retrieve all relevant files (code,
+configuration files like build scripts, SOUPs, etc.) at any time in the future.*
+
+*When a new software version is released, its commit is tagged in git. The tag is constructed by adhering to
+semver ([semver.org](https://semver.org)) 2.0.0 which results in a version of format MAJOR.MINOR.PATCH,
+e.g., 1.0.0.*
+
+## 6 Documentation Activities
+
+> Describe your policy on what should be documented while you develop software. Maybe you want to require
+> your developers to document all methods which are private. Maybe you want to keep an up-to-date software
+> architecture diagram in the repository, etc. Make sure to mention how traceability between Software Requirements and Tests is maintained.
+
+## 7 Implementation Verification Activities
+
+> Describe verification activities, e.g. code review.
+
+*For each pull request, a code review is performed by a team member who was not the main author of the code
+under review. The code review is only marked as "approved" if the code complies with the code review
+criteria. This is:*
+
+ * *Code fulfils the software requirements*
+ * *Adherence to [PEP8 Style Guide](https://www.python.org/dev/peps/pep-0008/)*
+
+## 8 Software System Test Activities
+
+> Describe software system test activities. This could be continuous integration which is triggered by opening
+> a pull request (e.g. Travis CI, Circle CI). Describe what is tested and how that automated system works.
+
+*Integration tests are included in software system tests.*
+
+## 9 Validation Activities
+
+Validation is carried out as formative and summative usability evaluation as described in the software development process. A usability evaluation file (plan, protocol and report) will be prepared.
+
+## 10 Maintenance Activities
+
+> Describe how often you check SOUP issue trackers and how you document them.
+
+*SOUP issue trackers are checked at least once every 6 months. The verification date is updated in the SOUP
+list accordingly.*
+
+---
+
+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.