diff --git a/DIN EN 62304/document-roadmap.md b/DIN EN 62304/document-roadmap.md new file mode 100644 index 0000000..ed0520f --- /dev/null +++ b/DIN EN 62304/document-roadmap.md @@ -0,0 +1,73 @@ +# Document Roadmap TechDoc + +This is a proposed roadmap to creating the TechDoc file. The documents are grouped by "Design Phase". To each +document, a responsible person is assigned as the author. Go through the list phase by phase. You can mix up +the order of documents within a phase, but I recommend to finalize documents from one phase before moving on +to the next. + +### PHASE 1: Planning & Feasability + +| Document | Author | Comment | +|-------------------------------------------------|-------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Intended Use | CEO | This is the most important document of your TechDoc. Business and Regulatory Strategy depend on it. | +| Medical Device Classification | QA/RA Manger | Defining the product's medical device classification acc. to MDR. | +| Product Roadmap | Product Manager | Not an essential document. This is for feasibility assessments and resource planning. Helps to keep track of what's to come. | +| Software Development and Maintenance Plan | Software Developer | Giving product-specific information on the tools, resources and methods to be used for software development. Helpful for developer teams to align regarding the development setup. | +| Change Evaluation List | QA/RA Manger | Listing and assessing gaps between the last and the upcoming software version. Follows criteria from MDCG 2020-3. Not needed for the very first release. | +| Risk Management Plan and Risk Acceptance Matrix | Risk Manager | Specifies the methods for assessing risks to be used for the product at hand. Defines probability and severity categories and acceptable ranges. | +| Clinical Evaluation Plan | Clinician / Scientific Person | Specifying the methodology that shall be used to assess the clinical benefits and risks of the product. | + +### PHASE 2: Specification + +| Document | Author | Comment | +|--------------------------------------|--------------------------------------|------------------------------------------------------------------------------------------------------------| +| User Needs List | Product Manager | This is a list of high-level requirements. Most of them will be implemented through Software Requirements. | +| User Needs Checklist | QA/RA Manager | Checking if the User Needs List makes sense. | +| Software Requirements List | Developer-adjacent person | Specifying how User Needs will be incorporated in the software. Describing the details of a feature. | +| List of Hazard-Related Use Scenarios | Risk Manager | Identifying scenarios in which users could be prone to hazards. | +| Risk Table | Risk Manager | Anticipating and assessing risks. Gathering input from various channels. | +| Software Requirements Checklist | QA/RA Manager | Checking if the Software Requirements List makes sense. | +| Software Test Plan | Software Developer | Defining tests for every Software Requirement and mapping them to each other. | +| Usability Test Plan | Product Manager / Usability Engineer | Specifying the methodologies to be used to conduct the Usability Test. | + +### PHASE 3: Development + +| Document | Author | Comment | +|-----------------------|--------------------|-----------------------------------------------------------------------------------------------------------------| +| SOUP List | Software Developer | List of external libraries, frameworks and packages used in the product, incl. their assessment of criticality. | +| Software Architecture | Software Developer | Description/Graphic outlining the software components and their interaction. | + +The actual programming work takes place in this phase. It makes sense to create the SOUP list and the software +architecture immediately before programming begins and to adjust them if anything changes during code +creation. These documents should actually be created in advance, but due to the iterative nature of software +development, it will not be possible to plan everything before the actual work begins. Therefore, it makes +sense to create them in parallel with the programming. + +### PHASE 4: Verification and Validation + +| Document | Author | Comment | +|----------------------------|--------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Software Test Results | QA Tester | Results of the Software Tests: passed or failed? | +| List of Known Anomalies | Software Developer / Product Manager | List of known bugs and failed software tests. Justification why the software can still be released without impacting benefit/safety and a timeline when those bugs will be fixed. | +| Instructions For Use | Person with the best overview | The name says it all. | +| Usability Test Protocol | Product Manager / Usability Engineer | Specifying the actual usability test cases: Testing User Needs, Hazard-Related Use Scenarios and Instructions for Use. | +| Usability Test Report | Product Manager | Summary of the results of the Usability Test. | +| Clinical Evaluation Report | Clinician / Scientific Person | Analysing scientific data to prove the products safety and efficacy. | +| Risk Management Report | Risk Manager | Summary of the Risk Management Activities | + +### PHASE 5: Product Release + +| Document | Author | Comment | +|----------------------------|---------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| GSPR List | QA/RA Manager | Checking if the "General Safety and Performance Requirements" are fulfilled. | +| PMS (/PMCF) Plan | QA/RA Manager | Planning the product-specific activities for Post-Market Surveillance. If the clinical data is not sufficient, also plan Post-Market Clinical Follow-Up activities. | +| Software Release Checklist | QA/RA Manager | Checking if all the requirements are fulfilled, if the documents are complete and if the product is safe to be used. | +| Release Notes | Product Manager OR Software Developer | Description of new features in the current release. | +| Declaration of Conformity | QA/RA and CEO | Declaring the product's conformity with the regulations and standards. | + +--- + +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/DIN EN 62304/software-architecture-checklist.md b/DIN EN 62304/software-architecture-checklist.md new file mode 100644 index 0000000..26448d6 --- /dev/null +++ b/DIN EN 62304/software-architecture-checklist.md @@ -0,0 +1,41 @@ +# Software Architecture Checklist + +**Regulatory references:** + +IEC 62304, para. 5.3.6 [class B, C] + +**Relevant other documentation:** + +* SOP Software Development +* User needs / stakeholder requirements +* Design input / software requirements +* Software architecture description +* (...) + +# 1. Checklist + +| Criteria | Pass / Fail | +|----------------------------------------------------------------------------------------------------------|-------------------------| +| The software architecture is in agreement with the software requirements. | ( ) Yes
( ) Improve: | +| All software systems are listed and their respective safety class is stated. | ( ) Yes
( ) Improve: | +| All software components are listed and described, including interfaces. | ( ) Yes
( ) Improve: | +| All software units are listed and described. | ( ) Yes
( ) Improve: | +| (Optional) Further architecture is described, e.g. databases, security and data protection requirements. | ( ) Yes
( ) Improve: | +| The software architecture can be implemented with our given resources. | ( ) Yes
( ) Improve: | + +# 2. Comments + +\ + +# 3. Results + +( ) Software Architecture passed\ +( ) Software Architecture not passed\ +( ) Software Architecture passed with the following obligations: \\ + +--- + +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/DIN EN 62304/software-architecture-description.md b/DIN EN 62304/software-architecture-description.md new file mode 100644 index 0000000..ecc1e26 --- /dev/null +++ b/DIN EN 62304/software-architecture-description.md @@ -0,0 +1,94 @@ +# 1. Regulatory References + +**Regulatory references:** + +IEC 62304, para. 5.3.1 and 5.3.2 [class B, C] + +**Relevant other documentation:** + +* SOP Software Development +* User needs / stakeholder requirements +* Design input / software requirements +* (...) + +# 2. Software Systems + +In compliance with DIN EN 62304, we subdivide our software on three levels: software systems, software +components and software units. + +> Here, describe your internal software systems. The IEC 62304 defines those as an “integrated collection of +> software items organized to accomplish a specific function or set of functions.” +> +> NOTE: Ideally, you would add an illustrating diagram to the Annex and reference it here. + +## 4.1. Frontend + +> Enter description, for example: +> +> * Function: user interface display +> * Software safety classification and rationale +> * Runtime +> * Deployment +> * User groups + +## 4.2. Backend + +> Enter description, for example: +> +> * Function: managing patient data and medical images. +> * Software safety classification and rationale +> * Runtime (e.g. JVM) +> * Deployment (e.g. Docker container) +> * User group + +## 4.3. Algorithm + +> Enter description, for example: +> +> * Function: taking medical images as input and output a prediction. +> * Software safety classification and rationale +> * Runtime (e.g. JVM) +> * Deployment (e.g. Docker container) +> * User group + +# 6. Software Units + +> Describe your internal software units. The IEC 62304 defines those as a “software item [any identifiable +> part of a program, i.e. source code, object code, control code, control data, etc.] that cannot be +> subdivided into other items”. For example: +> +> * Wearable device poller (regularly checks whether wearable device has new data and downloads it) +> * Notification service (sends messages to Apple / Google for push notifications of mobile apps) +> * (...) + +# 7. Database + +> Describe your databases. For example: +> +> * Relational database: Postgres v14 + +# 8. IT Security + +## 8.1. Encryption of data + +\ + +### 8.1.1. Data at rest + +\ + +### 8.1.2. Data in transit + +> Example content: +> +> * Data in transit is encrypted with state-of-the-art encryption, e.g. SSL, TLS. +> * Additionally, we create a Virtual Private Network (VPC) which prevents the Compute Instances from being +> exposed to the public internet. The algorithm and the database are therefore not publicly reachable; they +> are only reachable by the backend. + +--- + +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.