53 lines
2.8 KiB
Markdown
53 lines
2.8 KiB
Markdown
|
# Checklist: Software Release
|
||
|
|
||
|
| Classes | IEC 62304:2006 Section | Document Section |
|
||
|
| ------- | ---------------------- | ---------------- |
|
||
|
| A, B, C | 5.8.1 | (All) |
|
||
|
| A, B, C | 5.8.2 | (All) |
|
||
|
| A, B, C | 5.8.3 | (All) |
|
||
|
| A, B, C | 5.8.4 | (All) |
|
||
|
| B, C | 5.8.5 | (All) |
|
||
|
| B, C | 5.8.6 | (All) |
|
||
|
| A, B, C | 5.8.7 | (All) |
|
||
|
|
||
|
## Summary
|
||
|
|
||
|
This checklist is used to verify that documentation and activities are complete before releasing a new version of the product.
|
||
|
|
||
|
> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The main point is that, at minimum, the items below should be checked (and documented) before you release a new version of your software.
|
||
|
|
||
|
> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty much the bare minimum to be 62304-compliant.
|
||
|
|
||
|
## Checklist
|
||
|
|
||
|
The following documents are up to date:
|
||
|
|
||
|
> The table below shows examples only. Add - or reference - a list of all your required TechDoc records.
|
||
|
|
||
|
| Item | Yes | No | Comment |
|
||
|
| ---- | --- | --- | ------- |
|
||
|
| Device Description | | | |
|
||
|
| Clinical Evaluation | | | |
|
||
|
| Declaration of Conformity | | | |
|
||
|
| (...) | | | |
|
||
|
|
||
|
The following activities have been performed:
|
||
|
|
||
|
| Item | Yes | No | Comment |
|
||
|
| ---- | --- | --- | ------- |
|
||
|
| All relevant functionalities of the software have been specified; the Software Requirement List is complete and has been reviewed. | | | |
|
||
|
| All relevant risks (including risks of known anomalies) have been evaluated; the Risk Management Report is complete. | | | |
|
||
|
| Verification (as software system testing) has been completed. | | | |
|
||
|
| Design control traceability is ensured:<br>Stakeholder requirements can be traced to software requirements.<br>Software requirements can be traced to system tests.<br>Software requirements can be traced to software code implementation / software code reviews.<br>Software requirements can be traced to risks and risk control measures.<br>Stakeholder requirements can be traced to usability tests.<br>Hazard-related use scenarios can be traced to usability tests.<br>Hazard-related use scenarios can be traced to risks and risk control measures. | | | |
|
||
|
| A version number as defined in the Software Development Plan has been assigned and added as a tag to git. | | | |
|
||
|
| Software is registered with a Notified Body. | | | |
|
||
|
| If release includes substantial change: Notified Body has been informed. | | | |
|
||
|
| Label is applied correctly including CE marking. | | | |
|
||
|
|
||
|
---
|
||
|
|
||
|
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.
|