Product Release
Checklist Software Release
Verify documentation completeness and process compliance before releasing medical device software versions.
Summary
The Software Release Checklist is a comprehensive verification tool that ensures all documentation and required processes are completed before releasing a new version of your medical device software. This checklist validates compliance with IEC 62304 software lifecycle requirements and confirms that all regulatory documentation is current and accurate for the new software version.Why is Software Release Checklist important?
Medical device software releases require systematic verification to ensure patient safety and regulatory compliance. Each software version introduces potential new risks and must be thoroughly validated before market release. The release checklist serves as your final quality gate, preventing incomplete or non-compliant software from reaching patients and healthcare providers. This systematic approach demonstrates due diligence to regulatory authorities and provides documented evidence that all required processes were followed according to your established quality management system.Regulatory Context
Under 21 CFR Part 820 (Quality System Regulation):
- Design controls (820.30) require documented design validation before release
- Software validation guidance mandates release procedures for medical device software
- Change control (820.40) requires documentation of all software modifications
- Production and process controls (820.70) apply to software release processes
Special attention required for:
- Software validation in intended use environment before release
- Cybersecurity documentation updates for each release
- Predicate device comparison for substantial equivalence maintenance
- Post-market surveillance integration for software performance monitoring
Guide
Pre-Release Process Verification
Your release checklist must verify completion of all design control processes before software release. This includes confirming that software requirements are complete and traceable, risk management activities have evaluated all known anomalies, and verification activities through code review and system testing have been completed. The checklist ensures traceability from stakeholder requirements through software requirements to risk controls, system tests, and usability evaluation.Documentation Update Assessment
Each software release requires systematic review of all regulatory documentation to determine what needs updating. The checklist provides a comprehensive list of documents that may require updates, including user needs, intended use, risk management files, system and subsystem requirements, software architecture, test plans and reports, usability engineering files, clinical evaluation documents, instructions for use, and labeling documents. You must justify why documents were not updated if changes don’t affect their content.Version Control and Identification
Proper version identification according to your Software Development and Maintenance Plan is critical for traceability and regulatory compliance. The checklist verifies that version numbers are assigned correctly, tagged in your version control system, and properly reflected in all documentation. This ensures clear identification of what software version is being released and maintains traceability throughout the product lifecycle.Regulatory Registration Verification
Before release, verify that your software is properly registered with competent authorities and notified bodies as required for your device classification. For Class Im/Ir/Is, Class IIa, Class IIb, and Class III devices, registration with both competent authorities and notified bodies is mandatory. The checklist confirms these registrations are current and that notified bodies have been informed of significant changes as required.Labeling and Marking Compliance
The release checklist verifies that device labeling is correctly applied, including the CE mark for European markets. This includes confirming that the device label contains all required information, UDI-PI is updated for the new version, and all regulatory symbols and information are accurately displayed. Proper labeling is essential for market access and regulatory compliance.Change Impact Assessment
For each release, assess whether changes constitute significant modifications that require additional regulatory activities. Significant changes may require notified body notification, clinical evaluation updates, or additional testing. The checklist helps you systematically evaluate the impact of your changes and ensure appropriate regulatory steps are taken.Example
Scenario
You are releasing version 2.1.0 of your diagnostic imaging software that includes new AI algorithms for enhanced image analysis, improved user interface elements, and several bug fixes. The software processes medical images and provides diagnostic recommendations to radiologists in hospital settings.Example Software Release Checklist
Software Release Information
Software version for release: 2.1.0 Release date: March 15, 2024Process Verification Checklist
| Item | Yes / No | Comment |
|---|---|---|
| The Software Requirement List and Software Requirements List Checklist have been completed to ensure design specification has occurred. | Yes | Updated requirements for new AI algorithms documented in SRL-2024-003 |
| All relevant risks (including risks of known anomalies) have been evaluated; the Risk Management Report is complete. | Yes | Risk assessment updated for AI algorithm changes, no new unacceptable risks identified |
| Software verification in the form of code review and Software System Test Plan and Software System Test Reports have been completed if needed. | Yes | Code review completed for all AI algorithm changes, system testing passed all acceptance criteria |
| Design control traceability has been implemented | Yes | Traceability matrix updated to reflect new requirements and test cases |
| A version number as defined in the Software Development and Maintenance Plan has been assigned and added as a tag to git. | Yes | Version 2.1.0 tagged in Git repository on March 10, 2024 |
| Software is registered with the competent authority and with a Notified Body if Class Im/Ir/Is, Class IIa, Class IIb and Class III. | Yes | Class IIa device registered with TÜV SÜD, registration updated for new version |
| If release includes a significant change: Notified Body has been informed. | No | Changes assessed as non-significant, no notified body notification required |
| Label is applied correctly including CE mark | Yes | Device label updated with new version number and release date |
Documentation Update Assessment
| Document Name | Document Number | Updated | Justification for no update |
|---|---|---|---|
| User Needs List | UNL-2024-001 | No | AI algorithm improvements don’t change fundamental user needs |
| Intended Use | IU-2024-001 | No | Diagnostic imaging purpose remains unchanged |
| Risk Management Plan | RMP-2024-001 | Yes | Updated to include AI algorithm risk assessment procedures |
| Risk Assessment | RA-2024-002 | Yes | New risks evaluated for AI algorithm changes |
| Risk Management Report | RMR-2024-002 | Yes | Updated with AI algorithm risk evaluation results |
| System Requirements List | SRL-2024-003 | Yes | New requirements added for enhanced AI algorithms |
| Software Architecture | SA-2024-002 | Yes | Architecture updated to reflect AI algorithm integration |
| Software System Test Plan | SSTP-2024-002 | Yes | New test cases added for AI algorithm functionality |
| Software System Test Report | SSTR-2024-002 | Yes | Test results documented for version 2.1.0 |
| Instructions for Use | IFU-2024-001 | Yes | Updated to describe new AI algorithm features |
| Release Notes | RN-2024-002 | Yes | New release notes created for version 2.1.0 |
| Device Label | DL-2024-002 | Yes | Updated with new version number and release date |
Q&A
What should I do if I discover missing documentation during the release checklist?
What should I do if I discover missing documentation during the release checklist?
Stop the release process immediately and complete the missing documentation. Update your release checklist to reflect the completion of required documents before proceeding with the software release. This ensures regulatory compliance and patient safety.
How do I determine if my software changes are significant enough to require notified body notification?
How do I determine if my software changes are significant enough to require notified body notification?
Evaluate changes against your risk management criteria and regulatory guidance. Significant changes typically include new intended uses, major algorithm modifications, safety-critical functionality changes, or modifications that could affect clinical outcomes. When in doubt, consult with your regulatory affairs team or notified body.
What happens if I need to update documentation after completing the release checklist?
What happens if I need to update documentation after completing the release checklist?
Create a new version of the affected documents and update your release checklist accordingly. Document the reason for the late update and ensure all stakeholders are informed. Consider implementing process improvements to prevent similar issues in future releases.
How often should I update my software release checklist template?
How often should I update my software release checklist template?
Review and update your release checklist template whenever you add new document types to your quality management system, when regulatory requirements change, or when you identify process improvements. Ensure the checklist remains current with your actual documentation and processes.
Can I release software if some documentation updates are marked as 'No' in the checklist?
Can I release software if some documentation updates are marked as 'No' in the checklist?
Yes, if you provide adequate justification for why updates weren’t needed. The key is demonstrating that the unchanged documents remain accurate and current for the new software version. Unjustified ‘No’ responses may indicate incomplete release preparation.
How do I handle version control for the release checklist itself?
How do I handle version control for the release checklist itself?
Treat the release checklist as a controlled document with its own version number and approval process. Each software release should have its own completed checklist that becomes part of the permanent record for that release version.