compliance/tech-file
4
0
Fork 0
Code Pull Requests Packages Projects Releases Wiki Activity

uploaded new md templates

Browse Source
This commit is contained in:
René Herzer 2022-12-23 13:39:17 +01:00
parent 60923968e0
commit 9303ed9bad
3 changed files with 208 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
DIN EN 62304/document-roadmap.md Normal file
View File

@ -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.

41
DIN EN 62304/software-architecture-checklist.md Normal file
View File

@ -0,0 +1,41 @@
# Software Architecture Checklist
**Regulatory references:**
IEC 62304, para. 5.3.6 [class B, C]
**Relevant other documentation:**
* SOP Software Development
* User needs / stakeholder requirements
* Design input / software requirements
* Software architecture description
* (...)
# 1. Checklist
| Criteria | Pass / Fail |
|----------------------------------------------------------------------------------------------------------|-------------------------|
| The software architecture is in agreement with the software requirements. | ( ) Yes<br>( ) Improve: |
| All software systems are listed and their respective safety class is stated. | ( ) Yes<br>( ) Improve: |
| All software components are listed and described, including interfaces. | ( ) Yes<br>( ) Improve: |
| All software units are listed and described. | ( ) Yes<br>( ) Improve: |
| (Optional) Further architecture is described, e.g. databases, security and data protection requirements. | ( ) Yes<br>( ) Improve: |
| The software architecture can be implemented with our given resources. | ( ) Yes<br>( ) Improve: |
# 2. Comments
\<Insert comments if applicable\>
# 3. Results
( ) Software Architecture passed\
( ) Software Architecture not passed\
( ) Software Architecture passed with the following obligations: \<Insert if applicable\>\
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.

94
DIN EN 62304/software-architecture-description.md Normal file
View File

@ -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
\<enter content\>
### 8.1.1. Data at rest
\<enter content\>
### 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.