diff --git a/documentation/data/device.yml b/documentation/data/device.yml index 884287a..80d53d0 100644 --- a/documentation/data/device.yml +++ b/documentation/data/device.yml @@ -13,7 +13,7 @@ version: "v0.1.0" # "A" - No injury or damage to health is possible # "B" - Non-serious injury is possible # "C" - Death or serious injury is possible -safety_class: B +BS62304_class: B # The MHRA medical device classification for this applications # "I" - diff --git a/documentation/data/requirements.yml b/documentation/data/requirements.yml index 937848b..9544ca8 100644 --- a/documentation/data/requirements.yml +++ b/documentation/data/requirements.yml @@ -3,30 +3,34 @@ requirements: title: First Example Requirement type: Input/Output description: A brief description of the requirement; should use the world "shall". - specifications: | + priority: v1 - id: r-2 title: Second Example Requirement type: Functional description: Requirements describe what the software needs to do, and not how. + priority: v1 - id: r-3-1 title: Third Example Requirement Nested Id First Item type: Functional description: Requirements should be verifiable (e.g., testable). + priority: v1 - id: r-3-2 title: Fourth Example Requirement Nested Id Second Item type: Functional description: Requirements can be written using markdown. + priority: v1 + +sys_des_spec: + - id: SDS_001 + priority: v1.0.0 + title: Example design specification + type: Example design specification type + description: Example design specification description + linked_reqs: SRS-001 + - id: SDS_002 + priority: v1.0.0 + title: Example design specification + type: Example design specification type + description: Example design specification description + linked_reqs: SRS-002 -specification: - - id: sr-1 - title: some title - req_id: r-1 - description: Adds some descirptino to the specification - - id: sr-2 - title: some title - req_id: r-1 - description: Adds some descirptino to the specification - - id: sr-3 - title: some title - req_id: r-1 - description: Adds some descirptino to the specification diff --git a/documentation/data/risk.yml b/documentation/data/risk.yml index 2010c6d..382b94c 100644 --- a/documentation/data/risk.yml +++ b/documentation/data/risk.yml @@ -34,20 +34,15 @@ risk_acceptability_matrix: - [Low, Low, Medium, Medium, High] - [Low, Medium, Medium, High, High] risks: - - id: hz-1 - hazard: Incorrect information - software_item: Annotation Metric Calculator - events: | - - A software defect in the Annotation Metric Calculator causes the - size an annotated tumor to be significantly under-estimated - - The radiologist fails to notice the discrepancy - hazardous_situation: The oncologist is presented with incorrect tumor sizes - harm: An inappropriate therapy is given to the patient - severity: Catastrophic - probability: Low - control_measures: null - residual_severity: null - residual_probability: null - notes: Although it is not possible to estimate the probability of the - software defect occurring, it is unlikely that the radiologist would not - noticed the discrepancy. + - hazard_id: HZ-001-01 + hazard: Delays in treatment + causes: AIDE unavailable for technical reasons + effects: Delays in contouring and planning + harm: Patient distress and tumour progression + severity: Moderate + likelihood: 2 + risk: 2 + risk_control: Revert to manual contouring + residual_likelihood: 1 + residual_risk: 1 + comment: diff --git a/documentation/documents/.DS_Store b/documentation/documents/.DS_Store new file mode 100644 index 0000000..5008ddf Binary files /dev/null and b/documentation/documents/.DS_Store differ diff --git a/documentation/documents/acceptance_criteria.md b/documentation/documents/acceptance_criteria.md new file mode 100644 index 0000000..1dbacd7 --- /dev/null +++ b/documentation/documents/acceptance_criteria.md @@ -0,0 +1,70 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.012 +sop_version: +template_id: CSC F.030 +template_version: 2.0.1 +record_version: +record_id: AC-001 +title: Acceptance Criteria +--- + +# Acceptance Criteria + + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.026 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.012 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Purpose + +This document lists the tasks to be finalised, completed and approves before the application can be released to the +host department for routine clinical use. + + +## Scope + +This document applies to {{device.name}} release {{device.version}}. + +## Definitions + +| Term | Definition | +|-------|-------------| +| | | +| | | + +## Introduction + +## Criteria + +[TODO: append any other application tasks for the safe deployment of the application as agreed with the host department] + +| No. | Item | Signed | Date | +|-----|------------------------------------------------|--------|------| +| 1 | Clinical safety case report approved | | | +| 2 | All verification tests passed or justified | | | +| 3 | All validation tests passed or justified | | | +| 4 | Application deployed | | | +| 5 | Work instructions & Label provided | | | +| 6 | Service Level Agreement signed by both parties | | | +| 7 | Risk assessment provided | | | +| 8 | Retrospective evaluation completed | | | +| 9 | Prospective evaluation completed | | | +| 10 | Audit cycle and frequency confirmed | | | +| 11 | Post deployment surveillance plan confirmed | | | +| 12 | Communication channels confirmed | | | +| | | | | + diff --git a/documentation/documents/clinical_risk_management_plan.md b/documentation/documents/clinical_risk_management_plan.md index 0f17d0c..ca94764 100644 --- a/documentation/documents/clinical_risk_management_plan.md +++ b/documentation/documents/clinical_risk_management_plan.md @@ -1,35 +1,36 @@ --- -test: 123 +qms_version: 2.2.0 +sop_id: CSC PR.002 +sop_version: 2.0.1 +template_id: CSC F.009 +template_version: 2.0.1 +record_version: +record_id: CRMP-001 +title: Clinical Risk Management Plan --- # Clinical Risk Management Plan ## General ---- -test: 123 -Document: ID -Author: -Revision: -Regulatory References: ---- - - - - -| | | -|---------------------------|-----| -| **Document ID** | | -| **Author** | | -| **Revision** | | -| **Regulatory References** | | - +| | | +|---------------------------|--------------| +| **Template ID** | CSC F.009 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.002 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | ## Scope -This document applies to the {{device.name}} release {{device.version}}. +This document applies to the {{device.name}} version {{device.version}}. ## Purpose @@ -54,7 +55,7 @@ The document also provides traceability for risk controls throughout the project |----------------------------------|----------| | Hazard Log | HZ-001 | | Clinical Safety Case Report | CSCR-001 | -| Verification and Validation Plan | V&V-001 | +| Verification and Validation Plan | VVP-001 | ## Definitions @@ -167,10 +168,12 @@ Table X described the acceptability of estimated risks ### Risk Controls + Where risks exceed the acceptable level, risk controls will be implemented to reduced/remove likelihood of the causes of -the hazard occurring. -The effectiveness of each risk control with be verified with a unit test or a manual validation test. +the hazard occurring. Risks controls will be reflected a new system requirement item and system design item if not +already represented. The effectiveness of each risk control with be verified with a unit test or a manual validation +test. ### Evaluation of overall residual risk @@ -184,6 +187,7 @@ When the application development has finished and the clinical investigation has amendments to the Hazard Log, a Clinical Safety Case report will be approved by CSO. ### Deployment and Post-Deployment Activities + During and after deployment the hazard log will be updated in response to incidents, near misses and post deployment surveillance activities. diff --git a/documentation/documents/clinical_safety_case_report.md b/documentation/documents/clinical_safety_case_report.md new file mode 100644 index 0000000..b3243b3 --- /dev/null +++ b/documentation/documents/clinical_safety_case_report.md @@ -0,0 +1,234 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.002 +sop_version: 2.0.1 +template_id: CSC F.012 +template_version: 2.0.2 +record_version: +record_id: CSCR-001 +title: Clinical Safety Case Report +--- + +# Clinical Safety Case Report + +## General + +| | | +|---------------------------|----------------------------------| +| **Template ID** | CSC F.012 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.002 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | ISO14791
DCB0129
DCB0160 | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Document Management + +### Revision History + +| Version | Date | Author | Summary of Changes | +|---------|-------------|--------|--------------------| +| 0.1.0 | 01/01/2000 | | First Draft | + +### Reviewers + +| Review Name | Title/Responsibility | +|-------------|--------------------------------------| +| | Head of CSC /Clinical Safety Officer | +| | | + + +### Approval + +| Review Name | Title/Responsibility | Date | Version | +|-------------|----------------------|------|---------| +| | | | | + +### Related Documents + +| Document Reference Number | Title | Version | Status | +|---------------------------|-------|---------|--------| +| | | | | + +## Purpose + +This document reports the implementation, results and effectiveness of the clinical risk management activities outline +in the clinical risk management plan. + +## Scope + +This document applies to {{device.name}} {{device.version}}. + +## Out of Scope + +This CSCR does not cover use or trials outside of GSTT CSC MLOps and AIDE environment or performed by other teams and +institutions. + +## Roles and Responsibilities + +| Role | Responsibilities | +|-------------------------|------------------| +| Clinical Safety Officer | | +| Clinical Lead | | +| Development Lead | | + +## Definitions + +| Term | Definition | +|--------|--------------------------------| +| SRS | Software Requirements Spec | +| SDS | Software Design Spec | +| CSCR | Clinical Safety CAse Report | +| CRMP | Clinical Risk Management Plans | +| SWIFT | Structure What If | + + +## Executive Statement + +_Summary of the Clinical Safety Case Report findings and outcomes. This may include the purpose of the report, clinical context, summary of high value risks identified and their mitigations and any key findings and conclusions. This section should not go into detail but provide an overall summary of the report._ + +| Initial | Residual | Risk Rating | Definition | +|---------|----------|-------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| | | 5 | Unacceptable level of risk. Mandatory elimination or control to reduce risk to an acceptable level | +| | | 4 | Unacceptable level of risk. Mandatory elimination or control to reduce risk to an acceptable level | +| | | 3 | Undesirable level of risk. Attempts should be made to eliminate or control to reduce risk to an acceptable level. Shall only be acceptable when further risk reduction is impractical. | +| | | 2 | Acceptable where cost of further reduction outweighs benefits gained. | +| | | 1 | Acceptable, no further action required | + + +## Introduction + +_Purpose of the Clinical Safety Case Report and phase of lifecycle it relates to._ + +## System Definition / Overview + +_Description of the Health IT System; identification of Health IT System part and version number; description of the +clinical environment it is to be used in; description of any existing systems it replaces or interfaces with; number of +users and patients._ + +## Clinical Risk Management System +_Description of the Manufacturer’s clinical risk management system; identification of key personnel, their roles and +responsibilities; identification of clinical risk management governance structure._ + +The clinical risk management system is described in the Clinical Risk Management Plan document, which follows DBC0129 +[1]. The clinical safety case has been developed in accordance with the CSC QMS [2]. + +Clinical safety activities have been undertaken by the CSC team under the supervision and with collaboration with +the CSO. Persons responsible for this process are listed at the start of this CSCR. + +## Medical Device Declaration + +The {{device.name}} application has a Class {{device.mhra_class}} MHRA classification. + +[Guidance for MHRA classification](https://ec.europa.eu/docsroom/documents/10337/attachments/1/translations) + + +## Clinical Risk Analysis +_Hazard identification; description of patient safety consequences; explanation of hazard causes and contributory +conditions; identification of existing mitigating controls; estimation of clinical risk; identification of participating +personnel._ + +Risk analysis methods are explained in the Clinical Risk Management Plan. + +Hazard identification, risk evaluation and risk control meetings were conducted with key stakeholders throughout the +design and development stages. + +## Clinical Risk Evaluation +_Evaluation of initial level of risk of each identified hazard using pre-defined criteria._ + +Risks are evaluated against the severity and likelihood scales in appendix 1, taken from DCB 0129. + + +## Clinical Risk Control +_Identification, justification, implementation and verification of adequate risk controls; residual clinical risk +evaluation and completion of controls._ + +The risk controls identified against causes for risks which are evaluated as un-acceptable in the risk acceptability +chart in Appendix 2. + + + +## Hazard Log +The hazard log is available at release/hazard_log.md + +## Test Issues +Summary of any outstanding test issues and the impact on clinical safety. + +## Summary Safety Statement +Statement from the Clinical Safety Officer summarising the safety position of the Health IT System in the context of +the intended deployment. + +## Quality Assurance and Document Approval +Evidence of appropriate quality, review and approval regimes. + +## Configuration Control / Management +Evidence of appropriate configuration control being used. + + +## References + +- [1] DCB 0129 +- [2] DCB 0160 +- [3] ISO 14971:2019 + +--- +## Appendices + +### Appendix 1 + +#### Likelihood + + +| Likelihood | Interpretation | +|------------|--------------------------------------------------------------------------------------| +| Very High | Certain or almost certain; highly likely to occur | +| High | Not certain but very possible; reasonably expected to occur in the majority of cases | +| Medium | Possible | +| Low | Could occur but in the great majority of occasions will not | +| Very Low | Negligible or nearly negligible possibility of occurring | + + +#### Severity + + +| Severity classification | Interpretation | Number of patients affected | +|-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------| +| Catastrophic | Death

Permanent life-changing incapacity and any condition for which the prognosis is death or permanent life-changing incapacity; severe injury or severe incapacity from which recovery is not expected in the short term | Multiple | +| Major | Death

Permanent life-changing incapacity and any condition for which the prognosis is death or permanent life-changing incapacity; severe injury or severe incapacity from which recovery is not expected in the short term | Single | +| Major | Severe injury or severe incapacity from which recovery is expected in the short term

Severe psychological trauma | Multiple | +| Considerable | Severe injury or severe incapacity from which recovery is expected in the short

Severe psychological trauma | Single | +| Considerable | Minor injury or injuries from which recovery is not expected in the short term.

Significant psychological trauma | Multiple | +| Significant | Minor injury or injuries from which recovery is not expected in the short term.

Significant psychological trauma | Single | +| Significant | Minor injury from which recovery is expected in the short term

Minor psychological upset; inconvenience | Multiple | +| Minor | Minor injury from which recovery is expected in the short term; minor psychological upset; inconvenience; any negligible severity | Single | + +### Appendix 2 + +#### Risk Calculation + + +| Likelihood | | | | | | +|--------------|-----------|----------------|------------------|-----------|------------------| +| _Very High_ | 3 | 4 | 4 | 5 | 5 | +| _High_ | 2 | 3 | 3 | 4 | 5 | +| _Medium_ | 2 | 2 | 3 | 3 | 4 | +| _Low_ | 1 | 2 | 2 | 3 | 4 | +| _Very Low_ | 1 | 1 | 2 | 2 | 3 | +| **Severity** | _Minor_ | _Significant_ | _Considerable_ | _Major_ | _Catastrophic_ | + + +#### Risk acceptability matrix + +| Risk Level | Comment | +|------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 5 | Unacceptable level of risk
Mandatory elimination of hazard or addition of control measure to reduce risk to an acceptable level | +| 4 | Unacceptable level of risk
Mandatory elimination of hazard or addition of control measure to reduce risk to an acceptable level | +| 3 | Undesirable level of risk
Attempts should be made to eliminate the hazard or implement control measures to reduce risk to an acceptable level.
Shall only be acceptable when further risk reduction is impractical | +| 2 | Acceptable where cost of further reduction outweighs benefits gained or where further risk reduction is impractical | +| 1 | Acceptable, no further action required | diff --git a/documentation/documents/cyber_security.md b/documentation/documents/cyber_security.md index 9a591b7..b69a032 100644 --- a/documentation/documents/cyber_security.md +++ b/documentation/documents/cyber_security.md @@ -1,18 +1,42 @@ --- -id: CYBSEC-001 -revision: 1 +qms_version: 2.2.0 +sop_id: +sop_version: +template_id: CSC F.024 +template_version: 2.0.1 +record_version: +record_id: CYBSEC-001 title: Cybersecurity Risk Management Report --- -# Purpose +# Cyber Security + +## General + + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.024 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | +## Purpose The purpose of this document is to demonstrate the cybersecurity design controls and risk management found in {{device.name}} for FDA reviewers in a format that closely follows the 2018 Draft Guidance, "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices". -# Scope +## Scope This document applies to {{device.name}} release {{device.version}}. -# Cybersecurity Risk Tier +## Cybersecurity Risk Tier TODO: Select the appropriate cybersecurity risk tier, based on your device. Three possible wordings are provided for your convenience below. Include additional justification for your selection as appropriate. @@ -37,7 +61,7 @@ ENDTODO [[FDA-CYBER:4.1]] -# System Diagrams +## System Diagrams TODO: Add System Diagrams that are sufficiently detailed to permit an understanding of how the specific device design elements are incorporated into a system-level and holistic picture. Analysis of the entire system is necessary to understand the manufacturer’s threat model and the device within the larger ecosystem. System diagrams should include: @@ -53,19 +77,19 @@ ENDTODO [[These system diagrams fulfill FDA-CYBER:7.A.3, FDA-CYBER:7.A.3.a, FDA-CYBER:7.A.3.b, FDA-CYBER:7.A.3.c, FDA-CYBER:7.A.3.d, and FDA-CYBER:7.A.3.e]] -# Software Updates and Patches +## Software Updates and Patches TODO: Write a summary describing the design features that permit validated software updates and patches as needed throughout the life cycle of the medical device to continue to ensure its safety and effectiveness. [[FDA-CYBER:7.A.4]] -# Cybersecurity Design Controls +## Cybersecurity Design Controls TODO: Tier 1 devices should demonstrate how all design controls listed below are implemented. To do this, we recommend listing the associated requirements. Tier 2 devices may provide a risk-based rationale for why specific design controls are not appropriate. This section enumerates all of the design controls recommended by the FDA for easy review by an FDA auditor. -## Limit Access to Trusted Users & Devices Only +### Limit Access to Trusted Users & Devices Only *Limit access to devices through the authentication of users.* @@ -108,7 +132,7 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.A.1.a.vi]] -# Authenticate and Check Authorization of Safety-Critical Commands +## Authenticate and Check Authorization of Safety-Critical Commands *Use authentication to prevent unauthorized access to device functions and to prevent unauthorized (arbitrary) software execution.* @@ -167,7 +191,7 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.A.1.b.viii]] -## Code Integrity +### Code Integrity *Only allow installation of cryptographically verified firmware/software updates. Ensure that a new update is more recent than the currently installed version to prevent downgrade attacks.* @@ -184,7 +208,7 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.A.2.a.ii]] -## Data Integrity +### Data Integrity *Verify the integrity of all incoming data (ensuring it is not modified in transit or at rest, and it is well-formed/compliant with the expected protocol/specification).* @@ -222,7 +246,7 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.A.2.b.v]] -## Execution Integrity +### Execution Integrity *Where feasible, use industry-accepted best practices to maintain/verify integrity of code while it is being executed on the device.* @@ -231,7 +255,7 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.A.2.c.i]] -## Maintain Confidentiality of Data +### Maintain Confidentiality of Data *Manufacturers should ensure the confidentiality of any/all data whose disclosure could lead to patient harm (e.g., through use of credentials, encryption). Loss of confidentiality of credentials could be used by a threat to effect multi-patient harm. Lack of encryption to protect sensitive information "at rest" and “in transit” can expose this information to misuse that can lead to patient harm. Other harms, such as loss of confidential protected health information (PHI), are not considered “patient harms” for the purposes of this guidance.* @@ -240,7 +264,7 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.A.3]] -## Detect Cybersecurity Events in a Timely Fashion +### Detect Cybersecurity Events in a Timely Fashion *Implement design features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use.* @@ -291,7 +315,7 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.B.1.g]] -## Respond to and Contain the Impact of a Potential Cybersecurity Incident +### Respond to and Contain the Impact of a Potential Cybersecurity Incident *The device should be designed to notify users upon detection of a potential cybersecurity breach.* @@ -321,7 +345,7 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.B.2.d]] -## Design the Device to Recover Capabilities or Services that were Impaired Due to a Cybersecurity Incident +### Design the Device to Recover Capabilities or Services that were Impaired Due to a Cybersecurity Incident *Implement device features that protect critical functionality and data, even when the device’s cybersecurity has been compromised.* @@ -350,19 +374,19 @@ TODO: demonstrate how this is implemented, e.g., by printing out the associated [[FDA-CYBER:V.B.3.e]] -## Additional Controls +### Additional Controls TODO: List additional cybersecurity controls here -# Risk Management +## Risk Management -## System Level Threat Model +### System Level Threat Model TODO: Create a system level threat model that includes a consideration of system level risks, including but not limited to risks related to the supply chain (e.g., to ensure the device remains free of malware), design, production, and deployment (i.e., into a connected/networked environment). Its possible this could be combined with the systems diagrams. [[FDA-CYBER:7.B.1]] -## Cybersecurity Risk Assessment +### Cybersecurity Risk Assessment TODO: List out all cybersecurity risks. The tables shown here should probably be produced by filtering out data from `risk.yml` somehow. Ideally, the software engineers would be able to use the same process for safety and security risks. Note that TIR57 suggests keeping these processes separate, in part because the cybersecurity risk analysis doesn't require the full multi-domain risk team. That said, we already split the full risk management process from the software-specific risk process, thus splitting it again doesn't make sense. That said, there should probably be one cybersecurity expert on the software team. Perhaps this person should be added to the CODEOWNERS file for parts of the system that involve cybersecurity. diff --git a/documentation/documents/deployment_plan.md b/documentation/documents/deployment_plan.md new file mode 100644 index 0000000..107d478 --- /dev/null +++ b/documentation/documents/deployment_plan.md @@ -0,0 +1,70 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.012 +sop_version: 2.0.1 +template_id: CSC F.023 +template_version: 2.0.1 +record_version: +record_id: DLP-001 +title: Deployment Plan +--- + +# Deployment plan + + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.023 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.012 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Purpose and Scope + +This document applies to {{device.name}} release {{device.version}}. + +This document describes the deployment process to make the application available for clinical use. + +## Definitions + +| Term | Definition | +|-------|-------------| +| | | +| | | + +### Plan + + +#### Deployment Timeline + +#### Software Installation + +#### End User Acceptance Testing + +#### Risk Mitigation + +#### End User Training + + +#### Documentation Final Documentation Approvals + +#### Sign Off + +#### Post Deployment Surveillance Programme Confirmation + + + + + + + diff --git a/documentation/documents/design_plan.md b/documentation/documents/design_plan.md index c28543f..9d1a1af 100644 --- a/documentation/documents/design_plan.md +++ b/documentation/documents/design_plan.md @@ -1,23 +1,41 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.001 +sop_version: 2.0.1 +template_id: CSC F.008 +template_version: 2.0.2 +record_version: +record_id: DP-001 +title: Design Plan +--- # Design Plan + ## 1. General -| | | -|---------------------------|-----| -| **Document ID** | | -| **Author** | | -| **Approval** | | -| **Revision** | | -| **Regulatory References** | | + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.008 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | ## 2. Purpose This document describes a set of activities which will be used during software risk management, development, and maintenance of {{device.name}}. It is written primarily for software developers. -{{device.name}} is assigned a Class [CLASS] software safety class, which means non-serious injury could occur if the software fails. +{{device.name}} is assigned a Class {{device.mhra_class}} software safety class, which means non-serious injury could occur if the +software fails. All the software items that compose the software system are also presumed to have the same Class. The primary purpose of this document is to help developers ensure {{device.name}} is safe and useful while also allowing developers to be @@ -36,27 +54,31 @@ This document applies to {{device.name}} release {{device.version}}. ## 5. Roles and Responsibilities + | Role | Responsibilities | |------|------------------| | | | ## 6. Related Documents + + +| Document ID | Purpose | Link | +|-----------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------|------| +| Software Requirement Specification | Describes the user requirements, risk control to be implemented, and regulatory requirements need for design planning. | | +| Clinical Risk Management Plan (CRMP) | Lays out the clinical risk management frameworks, activities, and results. | | +| Hazard Log | The outputs of Risk analysis, assessment and mitigation processes conduct with key stakeholders. | | +| Software Design Specification (SDS) | Logs the outputs of the design activities in detail, tracing tasks back to the requirements | | +| Verification and validation plan | Describes the framework for ensuring the applications is built safely effective and to specification using automated and manual tests | | +| Verification and validation test record | Present the results of the automated and manual test to demonstrate the correct application has been built safely. | | +| Release Record | | | +| | | | -| Document ID | Purpose | Link | -|-----------------------------------------|---------|------| -| Software Requirement Specification | | | -| Clinical Risk Management plan (CRMP) | | | -| Hazard Log | | | -| Software Design Specification (SDS) | | | -| Verification and validation plan | | | -| Verification and validation test record | | | -| Release Record | | | -| | | | ___ ### Development Standards + - This application has been developed within an ISO 13485:2016-certified quality management system. - The development of this medical software application follows BS EN 62034:2006. @@ -75,10 +97,10 @@ from a range of stakeholders as new requirements and risks as identified, but on This project utilises the following tools for development: -| Software | Software Validation Report | -|------------------------------------------------|----------------------------| -| PyCharm 2022.1.1 (Professional Edition) | (add report from QMS) | - | XNAT (eXtensible Neuroimaging Archive Toolkit | (add report from QMS) | +| Software | Software Validation Report | +|------------------------------------------------------|----------------------------| +| PyCharm 2022.1.1 (Professional Edition) | (add report from QMS) | +| XNAT (eXtensible Neuroimaging Archive Toolkit
All software activity outputs will be stored in this Git repository, the associated GitHub issues, or the associated GitHub pull requests, unless explicitly noted otherwise. The software developers working on the project are responsible for keeping all software activity outputs within version control at the times specified in the activity descriptions. In the Software Design Specification, record details about the project's build process, including tool versions, -environment variables, e.t.c. Also document how the software can be reliably delivered to the point of use without +environment variables, etc. Also document how the software can be reliably delivered to the point of use without corruption or unauthorized change. Keep this planning document up to date as the project commences. @@ -135,6 +158,21 @@ In conjunction with the manufacturer's management, review and update as appropri contained within hazard log. +### Milestone Review Planning + +Each design and development milestone should be planned and tracked throughout the project. At each milestone a review of key work should take place. This can be done by a co-developer (peer review) or by a project development supervisor. + +| Milestone | Expected Completion Date | Review of work completed by | Review outcome| +|---------------------------------------|--------------------------|-----------------------------|---------------| +| Requirements gathering | | | | +| Architectural design | | | | +| Detailed design | | | | +| Software development | | | | +| Integration and systems testing | | | | +| Release | | | | + +_Add or remove milestones as appropiate to the project._ + ### Requirements Analysis Important software requirements should be enumerated at the start of the project. @@ -167,7 +205,7 @@ for several months can be captured in a single large change request. ### Release Planning -TBC +A plan to determine how each software version will be released. This should include what features are planned to be released within each version, the timeline for the releases and how the software will be released detailing the release process. The release process should include details of release, documentation creation or updates, verification and validation of new software version and if required updates to the clinical risk management hazard log and clinical safety case. Please refer to CSC-PR-025-Software-Release-Guidelines.md for further information on the software release process. ### Detailed design @@ -208,5 +246,3 @@ Verification: Ensure code changes: - The original problem is fixed and the problem report closed - Any adverse trends have been reversed. - -### Release diff --git a/documentation/documents/hazard_log.md b/documentation/documents/hazard_log.md index d65f746..1a03361 100644 --- a/documentation/documents/hazard_log.md +++ b/documentation/documents/hazard_log.md @@ -1,16 +1,93 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.002 +sop_version: 2.0.1 +template_id: CSC F.013 +template_version: 2.0.1 +record_version: +record_id: HZ-001 +title: Hazard Log +--- + # Hazard Log +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.013 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.002 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Scope + +This document applies to {{device.name}} {{device.version}}. + ## Purpose -This document presents the results of the clinical risk management activities. +This document contains the outputs of the risk assessment conducted in accordance with the Clinical Risk Management Plan. + +This document is meant to be read and agreed-upon by the project owners, the CSC team, and the Clinical Safety +Officer (CSO) during design and development. It provides traceability for risk controls throughout the project. + +## Related documents + +| Document Title | ID | +|----------------------------------|----------| +| Clinical Risk Management Plan | CRMP-001 | +| Clinical Safety Case Report | CSCR-001 | +| Verification and Validation Plan | V&V-001 | + +## Hazard log -## Definitions +| Hazard ID | Hazard | Possible causes | Effect | Harm | Severity | Likelihood | Initial risk | Risk Controls | Final Likelihood | Final Risk | Comment | +|-----------|--------|----------------|------------------|------|----------|------------|---------------------|---------------|-----------------|-------------------|-------------| +{%- for risk in risk.risks %} +| {{ risk.hazard_id }} | {{ risk.hazard }} | {{ risk.causes }} |{{ risk.effects }} | {{ risk.harm }} |{{ risk.severity }} |{{ risk.likelihood }} |{{ risk.risk }} | - {{ risk.risk_control }} | {{ risk.residual_likelihood }} |{{ risk.residual_risk }} |{{ risk.comment }} | +{%- endfor %} -## Hazard Log +## Hazard log - Verbose -| id | Hazard | Software Item | Cause | Harm | Severity | Likelihood | Risk | Control Measure | residual severity | residual Likelihood | Residual Risk | Comment | -|-----|--------|---------------|-------|------|----------|------------|------|-----------------|-------------------|---------------------|---------------|---------| +{% for risk in risk.risks%} +{% if risk.hazard != None %} +--- +### ID : {{risk.hazard_id}} +### Hazard: {{risk.hazard}} +### Harm : {{ risk.harm }} +Cause : {{risk.causes}} +Effect : {{risk.effects}} +
Initial Severity : {{risk.severity}} +
Initial Likelihood : {{risk.likelihood}} +
Initial Risk : {{risk.risk}} +
Control Measures : {{risk.risk_control}} +
Residual Probability : {{risk.residual_likelihood}} +
Residual Risk : {{risk.residual_risk}} +
Comment : {{risk.comment}} +

+{% else %} + ID : {{risk.hazard_id}} +
Cause : {{risk.causes}} +
Effect : {{risk.effects}} +
Initial Severity : {{risk.severity}} +
Initial Likelihood : {{risk.likelihood}} +
Initial Risk : {{risk.risk}} +
Control Measures : {{risk.risk_control}} +
Residual Probability : {{risk.residual_likelihood}} +
Residual Risk : {{risk.residual_risk}} +
Comment : {{risk.comment}} +

+{% endif %} +{% endfor %} diff --git a/documentation/documents/instructions_for_use.md b/documentation/documents/instructions_for_use.md new file mode 100644 index 0000000..28767b4 --- /dev/null +++ b/documentation/documents/instructions_for_use.md @@ -0,0 +1,71 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.004 +sop_version: +template_id: CSC F.028 +template_version: 2.0.1 +record_version: +record_id: WI-001 +title: Instructions for Use +--- + +# Instructions for Use + + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.028 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Purpose and Scope + +It is written primarily for engineers working on {{device.name}}, who have the source code available, in addition to this document. + +This document applies to {{device.name}} release {{device.version}}. + +## Definitions + +| Term | Definition | +|-------|-------------| +| | | +| | | + +## Label + +| | | +|------------------------|---| +| Manufacturer Name | | +| Manufacturer Address | | +| Medical Device Name | | +| Medical Device Version | | + +## Introduction + +## Contact Information + +| | | +|---------------------|------------------------------------| +| ************ | Clinical Scientific Computing Team | +| | | + +## Instructions For Use + +### Connectivity requirements + +### Precautions in the Event of Change in Performance + +### Expected Degree of Accuracy + +### Troubleshooting + diff --git a/documentation/documents/literature_review.md b/documentation/documents/literature_review.md new file mode 100644 index 0000000..8ccd0f0 --- /dev/null +++ b/documentation/documents/literature_review.md @@ -0,0 +1,59 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.001 +sop_version: 2.0.1 +template_id: CSC F.014 +template_version: 2.0.1 +record_version: +record_id: LR-001 +title: Literature Review +--- + +# Literature Review + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.014 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Purpose + +This document presents the results of a literature review justifying the development {{device.name}} + +## Scope + +This document applies to {{device.name}} release {{device.version}}. + +## Definitions + +| Item | Definition | +|------|------------| +| | | + +## Roles and Responsibilities + +| Role | Responsibilities | +|------|------------------| +| | | + + +### Introduction + +### Academic papers + +### Commercially available products + +## References + diff --git a/documentation/documents/medical_device_regulations_classification.md b/documentation/documents/medical_device_regulations_classification.md new file mode 100644 index 0000000..bcf8915 --- /dev/null +++ b/documentation/documents/medical_device_regulations_classification.md @@ -0,0 +1,60 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.001 +sop_version: 2.0.1 +template_id: CSC F.018 +template_version: 2.0.1 +record_version: +record_id: MDR-001 +title: Medical Device Regulation Classification +--- + +# Medical Device Classification + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.018 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | +## Purpose + +This document describes the medical device classification for {{device.name}} release {{device.version}}. + +## Scope + +This document applies to {{device.name}} release {{device.version}}. + +## Definitions + +| Item | Definition | +|------|------------| +| | | + +## Roles and Responsibilities + +| Role | Responsibilities | +|------|------------------| +| | | + + +## MHRA Classification and rationale + +| MHRA Classification | {{device.mhra_class}} | +|---------------------|-------------------------------| + +## Medical software classification and rationale - BS EN 62304:2020 + +| 62304 Classification | {{device.BS62304_class}} | +|----------------------|-------------| \ No newline at end of file diff --git a/documentation/documents/post_deployment_surveillance_plan.md b/documentation/documents/post_deployment_surveillance_plan.md new file mode 100644 index 0000000..d25f29f --- /dev/null +++ b/documentation/documents/post_deployment_surveillance_plan.md @@ -0,0 +1,177 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.005 +sop_version: 2.0.3 +template_id: CSC F.011 +template_version: 2.0.3 +record_version: +record_id: PMS-001 +title: Post Market Surveillance Plan +--- + +# Post-Deployment Surveillance Plan + +This plan describes product-specific post-deployment surveillance activities. + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.011 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.005 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +--- + +## Product + +| Product Name | Version | Surveillance Period | +| ------------ | ----------- | ------------------- | +| | | | + +## 1. General Considerations + +According to Annex III section 1.1 (b) MDR, the post-market surveillance plan shall cover: + +| MDR Requirement | Activity | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| A proactive and systematic process to collect any information referred to in point (a). The process shall allow a correct characterisation of the performance of the devices and shall also allow a comparison to be made between the device and similar products available on the market | Monitor compliance with the Minimum Reporting Standards for in vivo Magnetic Resonance Spectroscopy (MRSinMRS) checklist for: Hardware, Acquisition, Data Analysis Methods and Outputs. | +| Effective and appropriate methods and processes to assess the collected data; | Monitor compliance with the Minimum Reporting Standards for in vivo Magnetic Resonance Spectroscopy (MRSinMRS) checklist for: Data quality. | +| Suitable indicators and threshold values that shall be used in the continuous reassessment of the benefit-risk analysis and of the risk management as referred to in Section 3 of Annex I; | Risk management is ensured via a risk analysis in compliance with Chapter 1-3 of Annex I. | +| Effective and appropriate methods and tools to investigate complaints and analyse market-related experience collected in the field; | | +| Methods and protocols to manage the events subject to the trend report as provided for in Article 88, including the methods and protocols to be used to establish any statistically significant increase in the frequency or severity of incidents as well as the observation period; | | +| Methods and protocols to communicate effectively with competent authorities, notified bodies, economic operators and users; | | +| Reference to procedures to fulfil the manufacturers obligations laid down in Articles 83, 84 and 86; | | +| Systematic procedures to identify and initiate appropriate measures including corrective actions; | | +| Effective tools to trace and identify devices for which corrective actions might be necessary; | | +| A PMCF plan as referred to in Part B of Annex XIV, or a justification as to why a PMCF is not applicable. | | + +## 2. Data Collection Activities + +> Note: In the "Metric / Threshold" column there's a placeholder "(define)". Replace this with the metric and +> threshold you've decided upon. + +| Activity | Assigned To | Metric / Threshold | How Often? | +| ------------------------------------------------------------------------------------------------------------ | ---------------------------- | ------------------ | ----------------------------- | +| Incident documentation and analysis of undesirable side effects | QMO | (define) | 1/year on Jan 1st | +| Assess feedback (customer complaints, sales feedback) | Head of Product | (define) | 1/year on Jan 1st | +| Check SOUP for new published issues | Head of Software Development | N/A | 2/year on Jan 1st and Aug 1st | +| Research data about similar products in the market | QMO | (define) | 1/year on Jan 1st | +| Conduct post-market clinical follow-up activities as planned | Head of Medical Team | | | +| Research scientific publications | Head of Product | | | +| Research updates of standards and legislation | QMO | | | +| Analyze trends, decide on necessary measures and implement them | QMO | | 1 /year | +| Update risk management file | QMO | | | +| Compile post-market clinical follow-up report | Head of Medical Team | | | +| Compile Periodic Safety Update Report | Head of Product | | | +| Upload PSUR to Eudamed database | | | | +| Compile post-market surveillance plan and post-market clinical follow-up plan for next surveillance interval | | | | + +## 3. Data Collection Categories + +At minimum, the information required by the process for post-deployment surveillance is collected. For (enter +product name), the following categories of data will be collected specifically: + +### Information about other devices\* + +- [BfArM Field Corrective Actions][bfarm-fca] + - Keywords: + - Filter: + - Time span: +- [BfArM Recommendations][bfarm-rec] + - Keywords: + - Time span: +- [MHRA][mhra] + - Keywords: + - Filter: + - Time span: +- [Swissmedic: List of recalls and other field corrective actions][swissmedic] + - Keywords: + - Time span: +- [FDA Recalls: medical device recalls][fda-recalls] + - Keywords: + - Time span: +- [FDA Maude][fda-maude] + - Keywords: + - Time span: +- SOUP Incident Reports + - Go through SOUP list + - Research public incident reports of the last (enter time span) months + +### Other information about similar devices + +- Google News Search + - Filter: (define) + - Time span: +- (...) + +### Specialist literature / technical databases + +> Note: This chapter should analyze other publications applicable to our product which are not considered +> already (or typically) as part of the post-deployment clinical follow-up. + +- Pubmed + - Filter: (define) + - Time span: last 12 months +- (...) + +### Serious incidents of our medical device + +- Incident documentation + - None + +### Non-serious incidents and undesirable side-effects of our own medical device + +- Feedback and customer complaints + - None + +### Feedback we collect from our partners, users, distributors, importers + +- Feedback and customer complaints + - Filter: not hazard-related feedback, feedback to performance, safety or processes + - Time span: + +### Trends + +- Compile list of trends as described in the section below. + +## 4. Trend Analysis + +Trend analysis is performed with a focus on undesirable side-effects and non-serious incidents. The trend analysis data sources may include Application audit and system logs, AI model inference time, AI confirmation bias, AI automation bias, GitHub issues, Complaints, feedback meetings with staff. These will be +monitored if they impact the benefit-risk ratio in a negative way. + +Hazards in the risk table are compared to post-market surveillance results: + +- If post-deployment surveillance leads to the finding that the estimated **probability** was too low (= event + happened more often in post-market surveillance), actions are initiated as described in the SOP Post-Market + Surveillance. +- If post-deployment surveillance leads to the finding that the estimated **severity** was too low (= event + happened led to more serious harm in post-market surveillance), a CAPA is initiated. + + + +[bfarm-fca]: https://www.bfarm.de/SiteGlobals/Forms/Suche/EN/kundeninfo_Filtersuche_Formular_en.html?nn=4527724 +[bfarm-rec]: https://www.bfarm.de/EN/MedicalDevices/RiskInformation/Recommendations/_functions/_node.html +[mhra]: https://www.gov.uk/drug-device-alerts +[swissmedic]: https://fsca.swissmedic.ch/mep/ + + + +[fda-recalls]: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res.cfm?start_search=1&event_id=&productdescriptiontxt=&productcode=&IVDProducts=&rootCauseText=&recallstatus=¢erclassificationtypetext=&recallnumber=&postdatefrom=&postdateto=&productshortreasontxt=&firmlegalnam=&PMA_510K_Num=&pnumber=&knumber=&PAGENUM=100 +[fda-maude]: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm + +--- + +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. diff --git a/documentation/documents/revision_level_history.md b/documentation/documents/revision_level_history.md index a5b1936..e7cab96 100644 --- a/documentation/documents/revision_level_history.md +++ b/documentation/documents/revision_level_history.md @@ -1,19 +1,42 @@ --- -id: RLH-001 +qms_version: 2.2.0 +sop_id: CSC PR.025 +sop_version: 2.0.1 +template_id: CSC F.031 +template_version: 2.0.1 +record_version: +record_id: RLH-001 title: Revision Level History --- -# Purpose +# Revision Level History + +## General + +| | | +|---------------------------|--------------| +| **Template ID** | CSC F.026 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.025 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Purpose The purpose of this document is to provide a history of software revisions generated during product development. -[[FDA-SW:rlh]] -# Scope +## Scope This document applies to {{device.name}}, and includes changes made in release {{device.version}}. -# Tested Versions +## Tested Versions TODO: Indicate which version(s) were tested, including bench testing, animal testing, and clinical testing, if applicable. @@ -23,7 +46,7 @@ TODO: Indicate any differences between the tested version of software and the re of the potential effect of the differences on the safety and effectiveness of the device. If this information is covered in the test record, a reference to the record will suffice. -# History +## History TODO: Fill in a high-level summary of the changes that have been made in between each release. See [the guidance](https://innolitics.com/articles/premarket-submissions-for-device-software-functions/#i-revision-level-history) @@ -32,7 +55,7 @@ for a few additional details. These notes shouldn't be too detailed; they should This section provides a summarized history of software revisions generated during the course of product development. {% for version in versions | reverse %} -## {{device.name}} {{version.release_id}} ({% if version.date %}{{version.date}}{% else %}in progress{% endif %}) +### {{device.name}} {{version.release_id}} ({% if version.date %}{{version.date}}{% else %}in progress{% endif %}) {% for change in version.changes or [] %} - {{change}} {%- endfor %} diff --git a/documentation/documents/software_description.md b/documentation/documents/software_description.md index be2a1d0..9b0cf73 100644 --- a/documentation/documents/software_description.md +++ b/documentation/documents/software_description.md @@ -1,25 +1,52 @@ --- -id: SD-001 -revision: 1 +qms_version: 2.2.0 +sop_id: CSC PR.001 +sop_version: 2.0.1 +template_id: CSC F.017 +template_version: 2.0.1 +record_version: +record_id: SD-001 title: Software Description --- -# Purpose +# Software Description -This document provides an overview of the operationally significant features of the software within {{device.name}}, -using a format that is familiar to FDA reviewers. +## General -[[FDA-SW:sd]] +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.017 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | -# Scope -This document applies to {{device.name}} release {{device.version}}. +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | -TODO: Read through the sections below and fill in all the details as appropriate. You may want to reference -[Section VI.B](https://innolitics.com/articles/premarket-submissions-for-device-software-functions/#b-software-description) -of the 2021 Draft Guidance titled, "Content of Premarket Submissions for Device Software Functions". +## Purpose and Scope -# Software Specifics +This document provides an overview of the operationally significant features of the software within {{device.name}} +release {{device.version}}. + +## Definitions + +| Item | Definition | +|------|------------| +| | | + +## Roles and Responsibilities + +| Role | Responsibilities | +|------|------------------| +| | | + + +## Software Specifics **What programming languages and compiler versions are used? What hardware platforms are used?** @@ -38,7 +65,7 @@ explain the differences.** The intended release version is {{device.version}}. The documentation's version is the same. -# Software Operation +## Software Operation **Who operates the software (user)? The patient, a caregiver, a healthcare professional, or a combination thereof?** @@ -71,7 +98,7 @@ identify and address potential biases and limitations of the model(s)?** TODO: Fill this in, refer to another document, or indicate it's not applicable -# Software Inputs and Outputs +## Software Inputs and Outputs **What are the inputs and their format?** @@ -115,7 +142,7 @@ Yes, the software interacts with networked devices. Yes, the software uses cloud or network storage. -# Other Device Functions +## Other Device Functions This device does not contain any other device functions. @@ -129,21 +156,19 @@ For a multiple function device product, the device description should include a that could adversely impact the device function-under-review and should address how the device function-under-review is impacted by each of the “other functions.” -If the device function-under-review could be positively impacted by the “other function,” and the labeling reflects the -positive impact (labeled positive impact), the device description should include the information outlined above in +If the device function-under-review could be positively impacted by the “other function,” and the labelling reflects the +positive impact (labelled positive impact), the device description should include the information outlined above in regard to the positive impact of the “other function” on the device function-under-review. Sponsors may also describe “other functions” that either do not have an impact or could have a positive impact that is -not suggested in the labeling of the device function-under-review, to provide an explanation of how the device functions +not suggested in the labelling of the device function-under-review, to provide an explanation of how the device functions overall. ENDTODO -[[FDA-SW:sd-other]] - -# Additional Information +## Additional Information TODO: Consider and provide any additional information that will help capture all of the unique aspects of your device's software function and will streamline or further FDA’s understanding of the device’s functionality to facilitate the -review of a submission. Additional content should focus on the high risk parts of the device. Note also that more +review of a submission. Additional content should focus on the high-risk parts of the device. Note also that more information is not necessarily better. Remove this section if no additional information needs to be added. \ No newline at end of file diff --git a/documentation/documents/software_design_specification.md b/documentation/documents/software_design_specification.md deleted file mode 100644 index 434c486..0000000 --- a/documentation/documents/software_design_specification.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -id: SDS-001 -revision: 1 -title: Software Design Specification ---- - -# Purpose - -This document describes *how* {{device.name}} shall fulfill the requirements described in the software requirements specification. It discusses the computation hardware the software will be expected run on, the software system's architecture, functional specifications associated with each software requirement, and user interface mockups. - -It is written primarily for engineers working on {{device.name}}, who have the source code available, in addition to this document. - -[[The legacy Software option of 62304:4.4 is not in use here.]] - -[[FDA-SW:sds]] - -# Scope - -This document applies to {{device.name}} release {{device.version}}. - -# Definitions - -**Protected Health Information** (PHI) means individually identifiable information that is created by {{device.name}} and relates to the past, present, or future physical or mental health or condition of any individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual. - -**UI** is an acronym for user interface. - -# System and Software Architecture Diagrams - -The purpose of these diagrams are to present a high-level overview of the device design to facilitate a clear understanding of - -1. the software items and hardware components that make up the system -2. the relationships among them -3. the data inputs/outputs and flow of data among them -4. how users or external products, including IT infrastructure and peripherals, interact with the system. - -TODO: Add various diagrams to this section (e.g., block, state, flow, sequence, etc.) showing a detailed depiction of functional units and software items. Focus on the high risk parts of the application. The diagrams should be largely self-explanatory without additional context. The diagrams should contain references to the other parts of the SDS. If the device includes other software functions, i.e., functionality that is not itself a medical device, these should be clearly delineated. SOUP and OTS software items should also be delineated in the diagrams. - -See [Section VI.C](https://innolitics.com/articles/premarket-submissions-for-device-software-functions/#c-system-and-software-architecture-diagram) for additional guidance about the content and formatting of these diagrams, and [Appendix B](https://innolitics.com/articles/premarket-submissions-for-device-software-functions/#appendix-b-system-and-software-architecture-diagram-chart-examples) for examples. - -ENDTODO - -[[FDA-SW:ssad]] - -# Software Items - -TODO: Enumerate the various software items that your system comprises of, and document the design of each one. - -## Software Item A - -## Software Item B - -# SOUP Software Items - -This section enumerates the SOUP software items present within {{device.name}}. - -{% for s in soup %} -## {{s.title}} - -**Manufacturer:** -{% if s.manufacturer is defined %} -{{s.manufacturer}} -{% else %} -SOUP was developed collaboratively by the free open-source software community, and does not have a manufacturer in the traditional sense. -{% endif %} -**Version:** - -`{{s.version}}` -{% if device.safety_class != "A" %} -**Functional and Performance Requirements:** - -{{s.purpose}} - -**Hardware & Software Requirements:** -{% if s.requirements is defined %} -{{s.requirements}} -{% else %} -No noteworthy software or hardware requirements. -{% endif %} -**Known Anomalies:** -{% if s.anomaly_reference is not defined %} -Known anomaly list is not available. -{% else %} -{% if s.relevant_anomalies is not defined %} -No anomalies found that would result in incorrect behaviour for {{device.name}} leading to a hazardous situation. -{% else %} -{{s.anomalies}} -{% endif %} -**Open Anomaly List (Reference Only):** - -`{{s.anomaly_reference}}` -{%- endif %} -{%- endif %} -{% endfor %} - -# Functional Specifications -{% for spec in requirements.specification %} -## {{spec.title}} - -*Spec Item ID:* {{spec.id}} - -*Description* {{spec.description}} - -*Mapped Requirement* {{spec.req_id}} - -{% endfor %} - - -# User Interface Mockups - -TODO: - -If you have user interface mockups, this is a good place to put them. One strategy is to include a sub-section for each screen, along with its own image file. Here are some examples: - -## Screen One (PNG) - -Use something like: `![Screen One](./images/uimockups/example-ui-mockup-001.png)` - -Which produces: - -![Screen One](./images/uimockups/example-ui-mockup-001.png) - -## Screen Two (JPG) - -Use something like: `![Screen Two](./images/uimockups/example-ui-mockup-002.jpg)` - -Which produces: - -![Screen Two](./images/uimockups/example-ui-mockup-002.jpg) - -## Screen Three (PNG Online) - -Use something like: `![Screen Three](https://github.com/innolitics/rdm/raw/a29fed650e55b376157cebe8843b087209a0b92a/rdm/init_files/images/uimockups/example-ui-mockup-001.png)` - -Which produces: - -![Screen Three](https://github.com/innolitics/rdm/raw/a29fed650e55b376157cebe8843b087209a0b92a/rdm/init_files/images/uimockups/example-ui-mockup-001.png) - -ENDTODO \ No newline at end of file diff --git a/documentation/documents/software_plan.md b/documentation/documents/software_plan.md index 92fdb92..5744cae 100644 --- a/documentation/documents/software_plan.md +++ b/documentation/documents/software_plan.md @@ -8,11 +8,11 @@ title: Software Plan This document for the GSTT CSC Team plans how the software in {{device.name}} will be designed, developed, and maintained. It identifies the deliverables, tasks, roles and responsibilities involved in these processes. -{% if device.safety_class == "A" %} +{% if device.BS62304_class == "A" %} All software items in {{device.name}} are assigned a Class A software-safety class, which means no injury or damage to health could occur if the software fails [[62304:4.3.a]]. See {{workflow.risk_management_file}} for details. -{% elif device.safety_class == "B" %} +{% elif device.BS62304_class == "B" %} All software items in {{device.name}} are assigned a Class B software-safety class, which means non-serious injury could occur if the software fails [[62304:4.3.a]]. See {{workflow.risk_management_file}} for details. @@ -411,7 +411,7 @@ Also, document how the software can be reliably delivered to the point of use wi **Verification tasks:** See issue-layer activities -{% if device.safety_class != 'A' %} +{% if device.BS62304_class != 'A' %} ## Project - Initial Architectural Design @@ -659,7 +659,7 @@ It's critical that the product owner be present during most sprint planning meet Once you're ready for your changes to be reviewed, you must assign a reviewer to verify the changes. Select a reviewer (or multiple reviewers) as appropriate for the activities you performed. Each activity indicates who must verify the outputs. E.g., some activities require that the project lead be the reviewer. -{% if device.safety_class != 'C' %} +{% if device.BS62304_class != 'C' %} Occasionally, due to the absence of other reviewers or due to an internal testing deadline, it may be necessary to skip the pull request review. When this happens, the engineer should justify why a review wasn't necessary within the merge request comments or create a change request or a "TODO" to ensure verification occurs before the next release. @@ -928,7 +928,7 @@ Note that these tasks do not need to be performed in the order they're presented Show the software and hardware interfaces between the software items and external software [[62304:5.3.2]]. -{% if device.safety_class == 'C' %} +{% if device.BS62304_class == 'C' %} Identify any segregation between software items that is essential to risk control, and state how to ensure that the segregation is effective. For example, one may segregate software items by running them on different processors [[62304:5.3.5]]. @@ -938,7 +938,7 @@ Note that these tasks do not need to be performed in the order they're presented Textual descriptions are often necessary in addition to architectural diagrams. These detailed designs should be stored as closely as possible to their corresponding source files. (The `rdm collect` subcommand can pull comments from source files into YAML so they can be included in the SDS.) -{% if device.safety_class != 'C' %} +{% if device.BS62304_class != 'C' %} Include detailed descriptions if they seem useful. @@ -1104,7 +1104,7 @@ TODO: add a template document for the software risk management file The `version` of each SOUP is a unique identifier, which specifies the version of the SOUP which is used in the software [[62304:8.1.2.c]]. The version may follow varying formats, such as `1.0.13`, `1.2r5`, or even `2021-05-05`, as appropriate. -{%- if device.safety_class != "A" %} +{%- if device.BS62304_class != "A" %} The `purpose` of each SOUP describes the functional and performance requirements that are necessary for its intended use [[62304:5.3.3]]. diff --git a/documentation/documents/software_requirements_spec.md b/documentation/documents/software_requirements_spec.md index b3c0413..73c71b7 100644 --- a/documentation/documents/software_requirements_spec.md +++ b/documentation/documents/software_requirements_spec.md @@ -1,19 +1,32 @@ --- -documentid: srs-v1.0 -version: 1.0 - +qms_version: 2.2.0 +sop_id: CSC PR.001 +sop_version: 2.0.1 +template_id: CSC F.010 +template_version: 2.0.2 +record_version: +record_id: SRS-001 +title: System Requirements Specification --- -# System Requirements Specification - PROJECT +# System Requirements Specification + +## General -| | | -|-------------|-----------| -| Document Id | srs-v1.0 | -| Version | 1.0 | -| Author | | -| | | +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.010 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | ### Purpose This purpose of this document is to describe what the {{device.name}} application must do. @@ -55,14 +68,12 @@ The following stakeholders contributed to the requirements gathering process. ### Introduction - ### Users - -####Clinicians +[TODO: identify all potential users of the software and how they would expect it to work] +#### Clinicians #### Trust IT - ### Use Environments [EG: @@ -77,9 +88,16 @@ SyntheticCT generation. ] #### Use Case #1 +[TODO: The first use case should layout the process of the successful use of the software from end to end, which runs +without error] + #### Use Case #2 +[TODO: complete another use case describing incorrect use of the application/wrong inputs/system failures\hardware +failures/ etc and how the application would successfully handle these errors ] + ### Considerations + The following list of considerations has been compiled from relevant suggestions from ISO 13485, BSI 62304 and BSI 62366: @@ -118,16 +136,13 @@ is GSTT only for projects built under this QMS) - requirements of IT network, Trust IT integration - user maintenance requirements - software update requirements +- for non-dicom application consult information governance and information security for local requirements ### User requirements + -| Reference | Requirement title | Requirements Description | -|-----------|-------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| SRS-001 | Shall accept MRI DICOM images. | Shall accept only MRI DICOM images from set list of MR protocols.
Accepts DICOM Images from certain machines with radiotherapy treatment couch.
Accepts a full MRI full DICOM Study. | - - -| ID | Title | Description | -|--------|---------|---------------| -{%- for requirement in requirements.requirements %} -| {{ requirement.id }} | {{ requirement.title }} | {{requirement.description}} | -{%- endfor %} +| Reference | Requirement title | Requirements Description | Priority | +|-----------|----------------------|---------------------------|----------| +{%- for requirement in requirements.requirements %} +| {{ requirement.id }} | {{ requirement.title }} | {{ requirement.description }} |{{requirement.priority}}| +{%- endfor %} \ No newline at end of file diff --git a/documentation/documents/system_architecture_diagram.md b/documentation/documents/system_architecture_diagram.md new file mode 100644 index 0000000..66e4c55 --- /dev/null +++ b/documentation/documents/system_architecture_diagram.md @@ -0,0 +1,44 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.001 +sop_version: 2.0.1 +template_id: CSC F.016 +template_version: 2.0.1 +record_version: +id: SAD-001 +title: System Architecture Diagram +--- + +# System Architecture Diagram + +## General + +| | | +|---------------------------|--------------| +| **Template ID** | CSC F.016 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Purpose and Scope + +This document displays the detailed design of the system and software architecture. + +This document relates to {{device.name}} {{device.version}} + +## Diagram 1 - System Architecture Diagram + +[TODO: add system architecture diagram with any external connected systems, eg. PACS, databases etc] + +## Diagram 2 - Detailed Software Architecture Diagram + +[TODO: add details software subunits within the software, showing interconnectivity] + diff --git a/documentation/documents/system_design_specification.md b/documentation/documents/system_design_specification.md new file mode 100644 index 0000000..cac27ca --- /dev/null +++ b/documentation/documents/system_design_specification.md @@ -0,0 +1,182 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.001 +sop_version: 2.0.1 +template_id: CSC F.019 +template_version: 2.0.1 +record_version: +record_id: SDS-001 +title: Software Design Specification +--- + +# Software Design Specification + + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.019 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Purpose + +This document describes *how* {{device.name}} shall fulfil the requirements described in the software requirements +specification. It discusses the computation hardware the software will be expected run on, the software system's +architecture, functional specifications associated with each software requirement, and user interface mock-ups. + +It is written primarily for engineers working on {{device.name}}, who have the source code available, in addition to +this document. + +## Scope + +This document applies to {{device.name}} release {{device.version}}. + + +## Definitions + +| Term | Definition | +|-------|-------------| +| | | +| | | + +**Protected Health Information** (PHI) means individually identifiable information that is created by {{device.name}} +and relates to the past, present, or future physical or mental health or condition of any individual, the provision of +health care to an individual, or the past, present, or future payment for the provision of health care to an individual. + +**UI** is an acronym for user interface. + +# System and Software Architecture Diagrams + +The purpose of these diagrams are to present a high-level overview of the device design to facilitate a clear +understanding of + +1. the software items and hardware components that make up the system +2. the relationships among them +3. the data inputs/outputs and flow of data among them +4. how users or external products, including IT infrastructure and peripherals, interact with the system. + +TODO: Add various diagrams to this section (e.g., block, state, flow, sequence, etc.) showing a detailed depiction of +functional units and software items. Focus on the high risk parts of the application. The diagrams should be largely +self-explanatory without additional context. The diagrams should contain references to the other parts of the SDS. If +the device includes other software functions, i.e., functionality that is not itself a medical device, these should be +clearly delineated. SOUP and OTS software items should also be delineated in the diagrams. + + +See [Section VI.C](https://innolitics.com/articles/premarket-submissions-for-device-software-functions/#c-system-and-software-architecture-diagram) for additional guidance about the content and formatting of these diagrams, +and [Appendix B](https://innolitics.com/articles/premarket-submissions-for-device-software-functions/#appendix-b-system-and-software-architecture-diagram-chart-examples) for examples. + +ENDTODO + +[[FDA-SW:ssad]] + +## Software Items + +TODO: Enumerate the various software items that your system comprises of, and document the design of each one. + +### Software Item A + +### Software Item B + +## SOUP Software Items + +This section enumerates the SOUP software items present within {{device.name}}. + +{% for s in soup %} +### {{s.title}} + +**Manufacturer:** +{% if s.manufacturer is defined %} +{{s.manufacturer}} +{% else %} +SOUP was developed collaboratively by the free open-source software community, and does not have a manufacturer in the +traditional sense. +{% endif %} +**Version:** + +`{{s.version}}` +{% if device.BS62304_class != "A" %} +**Functional and Performance Requirements:** + +{{s.purpose}} + +**Hardware & Software Requirements:** +{% if s.requirements is defined %} +{{s.requirements}} +{% else %} +No noteworthy software or hardware requirements. +{% endif %} +**Known Anomalies:** +{% if s.anomaly_reference is not defined %} +Known anomaly list is not available. +{% else %} +{% if s.relevant_anomalies is not defined %} +No anomalies found that would result in incorrect behaviour for {{device.name}} leading to a hazardous situation. +{% else %} +{{s.anomalies}} +{% endif %} +**Open Anomaly List (Reference Only):** + +`{{s.anomaly_reference}}` +{%- endif %} +{%- endif %} +{% endfor %} + +## Functional Specifications + +{% for spec in requirements.sys_des_spec %} + +### {{spec.title}} + +**Spec Item ID:** {{spec.id}} + +**Description:** {{spec.description}} + +**Mapped Requirement(s):** {{spec.linked_reqs}} + +{% endfor %} + + + +## User Interface Mockups + +TODO: + +If you have user interface mockups, this is a good place to put them. One strategy is to include a sub-section for each +screen, along with its own image file. Here are some examples: + +### Screen One (PNG) + +Use something like: `![Screen One](./images/uimockups/example-ui-mockup-001.png)` + +Which produces: + +![Screen One](./images/uimockups/example-ui-mockup-001.png) + +### Screen Two (JPG) + +Use something like: `![Screen Two](./images/uimockups/example-ui-mockup-002.jpg)` + +Which produces: + +![Screen Two](./images/uimockups/example-ui-mockup-002.jpg) + +### Screen Three (PNG Online) + +Use something like: `![Screen Three](https://github.com/innolitics/rdm/raw/a29fed650e55b376157cebe8843b087209a0b92a/rdm/init_files/images/uimockups/example-ui-mockup-001.png)` + +Which produces: + +![Screen Three](https://github.com/innolitics/rdm/raw/a29fed650e55b376157cebe8843b087209a0b92a/rdm/init_files/images/uimockups/example-ui-mockup-001.png) + +ENDTODO \ No newline at end of file diff --git a/documentation/documents/training_data.md b/documentation/documents/training_data.md new file mode 100644 index 0000000..72afd32 --- /dev/null +++ b/documentation/documents/training_data.md @@ -0,0 +1,135 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.001 +sop_version: 2.0.1 +template_id: CSC F.027 +template_version: 2.0.1 +record_version: +record_id: TD-001 +title: Training data +--- + +# Training Data + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.027 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.001 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | + +## Purpose + +This document describes the data collection and processing procedure for {{device.name}} {{device.version}}, including +demographic breakdown of the subjects in training and testing datasets. + +## Scope + +This document applies to data used for the development of {{device.name}}, and includes changes made in release +{{device.version}}. + +## Definitions + +| Item | Definition | +|------|------------| +| | | +| | | + +## Datasets + +### 1. Data Curation, Verification and Exclusion + +[TODO: Identify the sources of the data used in the development of the application. ] + +### 2. Demographics Information and Bias Identification + +[TODO: Discuss the demographic splits between sex, ethnicity, age etc and any biases, and how they were handled.] + +| | Positive | Negative | +|--------|----------|----------| +| Male | | | +| Female | | | + + +| | Positive | Negative | +|----------------|----------|----------| +| Not specified | | | +| Asian | | | +| Black | | | +| Latin American | | | +| Mixed | | | +| White | | | + + +| Male | Positive | Negative | +|------------|----------|----------| +| 0-15 | | | +| 16-20 | | | +| 21-25 | | | +| 26-30 | | | +| 31-35 | | | +| 36-40 | | | +| 41-45 | | | +| 46-50 | | | +| 51-55 | | | +| 56-60 | | | +| 61-65 | | | +| 66-70 | | | +| 71-75 | | | +| 76-80 | | | +| 81-85 | | | +| 86-90 | | | +| 91+ | | | + + +| Female | Positive | Negative | +|-------------|----------|----------| +| 0-15 | | | +| 16-20 | | | +| 21-25 | | | +| 26-30 | | | +| 31-35 | | | +| 36-40 | | | +| 41-45 | | | +| 46-50 | | | +| 51-55 | | | +| 56-60 | | | +| 61-65 | | | +| 66-70 | | | +| 71-75 | | | +| 76-80 | | | +| 81-85 | | | +| 86-90 | | | +| 91+ | | | + +### 3. Anonymisation and Psuedonymisation Methods + +[TODO: Outline the psuedonymisation schema, anonymised data, along with the rationale] + +### 4. Dataset Version and Identification + +[TODO: State the current version of the dataset used during development ] + +### 5. Data Labelling + +[TODO: Describe methods of labelling, the staff responsible, qualification level, any assistive tools used etc] + +### 6. Data Transformation and enrichment + +[TODO: Systematic data transformations applied and rationale, eg cropping, normalisation etc ] + +### 7. Data Storage and Access Control + +[TODO: who has access and why. Who "gate keeps" access the data] + + diff --git a/documentation/documents/unresolved_anomalies.md b/documentation/documents/unresolved_anomalies.md index 00409f8..764b274 100644 --- a/documentation/documents/unresolved_anomalies.md +++ b/documentation/documents/unresolved_anomalies.md @@ -1,20 +1,39 @@ --- -id: UA-001 -revision: 1 +qms_version: 2.2.0 +sop_id: +sop_version: +template_id: CSC F.022 +template_version: 2.0.1 +record_version: +record_id: UA-001 title: Unresolved Anomalies --- -# Purpose +# Unresolved Anomalies -The purpose of this document is to provide a list of all the problem reports for known software anomalies in the device. +## General -[[FDA-SW:ua]] +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.022 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | -# Scope + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | +## Purpose and Scope + +This document describes any unresolved anomalies identified during the development process. This document applies to {{device.name}}, and includes changes made in release {{device.version}}. -# Known Anomalies +## Known Anomalies This section includes a list of outstanding problem reports (i.e., known anomalies). Each problem report includes a description of the problem, its impact on device performance, and any plans or timeframes for correcting the problem (where appropriate). diff --git a/documentation/documents/verification-and-validation-plan.md b/documentation/documents/verification-and-validation-plan.md index 7413116..cc7d4ab 100644 --- a/documentation/documents/verification-and-validation-plan.md +++ b/documentation/documents/verification-and-validation-plan.md @@ -1,28 +1,42 @@ --- -documentid: v&v-v1.0 -version: 1.0 +qms_version: 2.2.0 +sop_id: CSC PR.003 +sop_version: 2.0.1 +template_id: CSC F.020 +template_version: 2.0.1 +record_version: +record_id: VVP-001 +title: Verification and Validation Plan --- -# Verification and Validation +# Verification and Validation Plan + +## General -| | | -|-------------|----------| -| Document Id | v&v-v1.0 | -| Version | 1.0 | -| Author | n | -| | | +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.020 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.003 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | -### Purpose +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | -This document describes a set of activities which will be used for the verification and validation of the software +### Purpose and Scope -### Scope +This document describes a set of activities which will be used for the verification and validation of the software This document applies to {{device.name}} release {{device.version}}. + ### Definitions | Term | Definition | @@ -40,28 +54,24 @@ This document applies to {{device.name}} release {{device.version}}. | Clinical Lead | | Review Verification and validation test | | CSO | | Ensure Risks controls and verified/validated | - -### Related Documents - -The following documents are related to design and development activities and contains records - -| Document id | Purpose | -|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Software Requirements Specification (SRS) | Describes what the software needs to accomplish. It is largely written by the project lead during the requirements gathering and analyiss stage, and is reviewed by the project lead during the release. Software developers may clarify and extend the document slightly during the unit implementation and testing activity | -| Clinical Risk Management plan (CRMP) | | -| Software Design Specification (SDS) | Describes how the software accomplishes what the SRS requires. A significant portion is written by the project lead during the architectural design, but many details and specifics are added by software developers during the unit implementation and testing activity. It is reviewed for consistency by the project lead during the release activity. | -| Device Classification | | -| Test Record | Describes a set of tests which were run, when, and by who. It also must include enough details to reproduce the testing setup. | -| Release Record | Describes the verifications steps performed by the project lead during the release. | +| Document id | Purpose | +|-------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Software Requirements Specification (SRS) | Describes what the software needs to accomplish. It is largely written by the project lead during the requirements gathering and analysis stage, and is reviewed by the project lead during the release. Software developers may clarify and extend the document slightly during the unit implementation and testing activity | +| Clinical Risk Management plan (CRMP) | | +| Software Design Specification (SDS) | Describes how the software accomplishes what the SRS requires. A significant portion is written by the project lead during the architectural design, but many details and specifics are added by software developers during the unit implementation and testing activity. It is reviewed for consistency by the project lead during the release activity. | +| Device Classification | | +| Verification and validation results | Presents the results of tests which were run, when, and by who. | +| Release Record | Describes the verifications steps performed by the project lead during the release. | ### 1. Verification plan + #### 1.1 Unit tests overview The main method of verifying the code has been written correctly is to generate and perform unit tests. -- Unit tests will be created to cover >90% of the code. +- Unit tests will be created to cover > 90% of the code. - Tests will be written for each item in the design specification. - Unit tests will be reviewed at key stages of the development process. - Each Pull Request should only be merged where all unit tests pass. @@ -69,26 +79,34 @@ The main method of verifying the code has been written correctly is to generate #### 1.2 Unit tests -| Design spec item | Unit Tests | Expected Results | Results | -|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|------------------|---------| +| Design Spec. Item | Unit Tests | Expected Results | +|-------------------|------------|------------------| ### 2. Validation plan + -#### 2.1 Validation test Overview +#### 2.1 Validation Test Overview -Validation tests are manual checks and tasks performed to ensure the correct application has been built. +Validation tests are typically manual checks and tasks performed to ensure the correct application has been built. - Validation tests are performed by the software developer to check that the software meets all items identified in the System requirements specification. - In addition, validation tests can also capture design specification items that cannot be verified with automated unit tests. +- It is ok if some tests do not trace to any particular requirements, however all requirements must be covered by some +tests (if they are not, add tests). + #### 2.2 Validation tests + + + +| Design Spec. Item | Test(s) | Expected result | +|-------------------|-----------|---------------------| + -| Design Spec Item | Test(s) | Performed by | Expected result | Result | -|------------------|----------------------------------------------------------------------------------------------------------------------------------------------|------------------|---------------------|--------| +| Requirements Spec. Item | Test(s) | Expected result | +|-------------------------|-----------|-------------------| -| Requirements spec item | Test(s) | Performed by | Expected result | Result | -|------------------------|-----------------------------------------------------------------------------|------------------|-----------------|--------| diff --git a/documentation/documents/verification_and_validation_results.md b/documentation/documents/verification_and_validation_results.md new file mode 100644 index 0000000..bcfc63c --- /dev/null +++ b/documentation/documents/verification_and_validation_results.md @@ -0,0 +1,116 @@ +--- +qms_version: 2.2.0 +sop_id: CSC PR.003 +sop_version: 2.0.1 +template_id: CSC F.021 +template_version: 2.0.1 +record_version: +record_id: VVR-001 +title: Verification and Validation Results + +--- + +# Verification and Validation Results + + +## General + +| | | +|---------------------------|---------------| +| **Template ID** | CSC F.021 | +| **Template Version** | 2.0.1 | +| **QMS Version** | 2.2.0 | +| **SOP ID** | CSC PR.003 | +| **SOP Version** | 2.0.1 | +| **Regulatory References** | | + + +| | | +|--------------|--------------| +| **Author** | | +| **Approval** | | +### Purpose and Scope + +This document presents the test results of all verification and validation tests to prove each system design +specification item and each system requirements is successfully implemented. + +This document applies to {{device.name}} release {{device.version}}. + +### Definitions + +| Term | Definition | +|---------|---------------------------------------------------| +| SRS | Software Requirements Spec | +| SDS | Software Design Spec | + + +### Roles and Responsibilities + +| Role | Name | Responsibilities | +|------------------|------|---------------------------------------------------------------------------------------| +| Development lead | | Completing documentation
Generating Unit tests
Performing validation tests | +| ML Lead | | Reviewing ML activities | +| Clinical Lead | | Review Verification and validation test | +| CSO | | Ensure Risks controls and verified/validated | + + +### Related Documents + +The following documents are related to design and development activities and contains records + +| Document id | Purpose | +|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Software Requirements Specification (SRS) | Describes what the software needs to accomplish. It is largely written by the project lead during the requirements gathering and analysis stage, and is reviewed by the project lead during the release. Software developers may clarify and extend the document slightly during the unit implementation and testing activity | +| Clinical Risk Management plan (CRMP) | | +| Software Design Specification (SDS) | Describes how the software accomplishes what the SRS requires. A significant portion is written by the project lead during the architectural design, but many details and specifics are added by software developers during the unit implementation and testing activity. It is reviewed for consistency by the project lead during the release activity. | +| Device Classification | | +| Test Record | Describes a set of tests which were run, when, and by who. It also must include enough details to reproduce the testing setup. | +| Release Record | Describes the verifications steps performed by the project lead during the release. | + + +### 1. Verification Test results + + +#### 1.1 Unit tests overview + +The main method of verifying the code has been written correctly is to generate and perform unit tests. + +- Unit tests will be created to cover >90% of the code. +- Tests will be written for each item in the design specification. +- Unit tests will be reviewed at key stages of the development process. +- Each Pull Request should only be merged where all unit tests pass. + +##### 1.2 Test Environment Configuration + +[TODO: describe the environment configuration used to run the unit tests, eg python env, requirements list, docker, +GitHub actions, etc ] + +#### 1.3 Unit tests + +| Design Spec. Item Id | Unit Tests | Expected Results | Results | Performed By | Date | +|----------------------|------------|------------------|---------|----------------|------| + + +### 2. Validation Test Results + + +#### 2.1 Validation test Overview + +Validation tests are manual checks and tasks performed to ensure the correct application has been built. +- Validation tests are performed by the software developer to check that the software meets all items identified in the +System requirements specification. +- In addition, validation tests can also capture design specification items that cannot be verified with automated unit +tests. + +#### 2.2 Validation Test environment configuration + +[TODO: describe the environment configuration used for the manual tests] + +#### 2.3 Validation tests + +| Design Spec. Item id | Test(s) | Performed by | Expected result | Result | Date | +|----------------------|------------|------------------|---------------------|--------|-------| + + +| Requirements Spec. Item Id | Test(s) | Performed By | Expected Result | Result | Date | +|----------------------------|-----------|--------------|-------------------|---------|-------|