I’m often asked “How frequently can we release our medical-device software?” Usually the person asking is a software-engineer who has used agile in another field and is used to frequent rapid releases—even multiple each day.
The short answer is: You can release software updates as frequently as you want so long as:
- The changes don’t require regulatory submissions
- You can produce all of the necessary design change documentation.
In practice, we’ve seen software development firms who can release updates as quickly as every two weeks. Usually, however, monthly or quarterly releases are more realistic.
In the remainder of this article, I discuss each of these two factors in more detail. I’ll focus on class-II devices that need a 510(k), since these are the most common type of SaMD. Similar logic applies to other types of premarket submissions.
Types of Releases 🔗
The first release for medical-device software is the most difficult and time-consuming. It usually culminates in a 510(k) submission.
After the first release, there will often be a sequence of smaller releases.
We generally lump them into three categories:
- Major Releases - Significant changes which will likely require another 510(k) submission.
- Minor Releases - Non-significant changes/updates which will not likely require a 510(k).
- Patch Releases - Small releases typically meant to fix an urgent cybersecurity issue or bug. A Patch Release is not intended for releasing new features/functions.
The amount of documentation work will vary depending on the type of the release.
Often, the important question to start with, is whether your software changes necessitate a 510(k).
Do We Need Another 510(k)? 🔗
If software changes “significantly affects the safety or effectiveness of the device” or the “Indications for Use”, then you will likely need to submit a 510(k) to the FDA before you can release it. I.e., your changes are for a Major Release. Putting the documentation together can take a while and the FDA will take at least a couple of months to review the submission.
The 2017 FDA Guidance, “Deciding When to Submit a 510(k) for a Software Change to an Existing Device,” discusses this topic in more detail. Here are examples of changes that likely require a 510(k):
- A change that introduces a new risk or modifies an existing risk that could result in significant harm
- Changes made to significantly improve clinical outcomes
- Changes to mitigate a safety risk that was identified
- Changes made in response to an adverse event that was reported
Here are a few examples that will NOT require a 510(k):
- Changes made solely to strengthen cybersecurity
- Changes made solely to return the system to within specification (i.e., just fixing a bug)
- Slight user interface changes (changing a logo or making a font-size larger)
- Limited scope performance optimizations
- Modifications or additions of “other functions” that don’t have significant affects on the safety risk assessment.
Even if the medical device is software only (SaMD), it is important to also assess the changes using the “Deciding When to Submit a 510(k) for a Change to an Existing Device” FDA guidance document. This guidance is intended to be used in conjunction with the software change guidance linked earlier. It covers other types of changes which may be made to a SaMD device. An example would be a change to the Indications for Use statement or a change to the warnings and precautions in the User Manual.
If the changes to the software device do not fall into the “Patch Release” category, the two FDA guidances should be used to create a “Note to File”. The “Note to File” document includes is created by using the various flowcharts within the guidance documents and documenting a response (including specific details) for every decision point. Whether to “submit” or “not submit” will be determined by the result of the “Note to File”. The “Note to File” should be placed in your Document Control System in the Design History File (DHF) for the version of software being released. If the changes fall into the Patch Release category, a ‘Regulatory Assessment’ should be included in the DHF stating that the changes were limited to cybersecurity enhancements and/or anomaly (bug) corrections.
When developing a regulatory strategy for your device, it’s a good idea to consider which features are likely to require a 510(k) and to try to lump them together. Good regulatory consultants will help you do this, especially if they understand software development.
Documenting a Major Release 🔗
A Major Release should be done according to the manufacturer’s Product Development Process (PDP). In many ways, a Major Release is documented in the same way as a new product release. The main difference is that the design documents already exist at a particular revision level (i.e., Revision A). The design documents will need to be reviewed and updated as applicable to fully document the release. The determination whether a regulatory submission ‘510(k)’, is needed will be documented in the ‘Note to File’ which will be filed within the DHF for the version
Documenting a Minor Release 🔗
As mentioned above, if you determine that a change does not require a 510(k) submission, then you can document your changes in a QMS using a “note to file.”
Here is a set of activities that usually need to be performed:
| Activity | Description | Methods to Speed up the Process |
|---|---|---|
| Change Control | The process of managing and documenting changes made to the system. It ensures changes are reviewed, approved, implemented, and validated. | Use template forms to standardize and speed up documentation. |
| Safety Risk Assessment | Identifying and assessing potential risks to patient safety resulting from the software change. | Hold a standing meeting with the cross-functional risk-management team. |
| Security Risk Assessment | Evaluating potential security vulnerabilities introduced or affected by the software change. | Utilize automated vulnerability scanning tools. Maintain a security standards checklist that any change must adhere to. |
| Design Inputs | Specifications and requirements that define how the system should behave. | Maintain a comprehensive, well-organized requirements management tool. Encourage developers to use standardized templates for new requirements. |
| Design Outputs | The results, products, or deliverables of the design inputs. Typically, this is the actual software, diagrams, and related documentation. | Use auto-generation tools for documentation where possible. |
| Design Review | Formal review of design outputs to ensure they meet design input requirements. | Hold regular design review meetings with predefined checklists. Use peer review processes for efficiency. |
| Design Verification | Process of ensuring the software meets the specified design inputs. This involves testing, regression testing, and deciding when tests are needed. | Automate the testing processes using continuous integration (e.g., we like GitHub Actions). Maintain a library of regression tests that can be run as needed. Ensure tests are modular to allow easy modification. |
| Document Control | Managing and maintaining all formal documents to ensure they're up-to-date, approved, and available to all relevant parties. | Avoid files and use live online documents (e.g., Notion or Google Docs) instead. |
| Labeling | The software ‘label’ must be updated to reflect the new version | Have a standard process (i.e., release checklist) that includes a task to update the labeling. Automate the collation of the user manual. |
| SBOM | The Software Bill of Materials | If any third-party dependencies were added or versions changed, then a new SBOM is required. Auto-generate your SBOM as part of your CI/CD pipeline. |
| Design Validation | Confirming that the system operates as intended in the real-world scenario. This may involve clinical testing or field testing. | Use simulation tools to mimic real-world scenarios. Gather continuous feedback from users for early validation. Write your procedures in a way that allow you to skip validation when the user interface and user manual don’t change. |
Documenting a Patch Release 🔗
As with the Major and Minor release types, Patch Releases must also be released in a controlled manner. The difference is that as Patch Releases are very limited in scope (Cybersecurity enhancements, anomaly (bug) corrections), the amount of documentation is also limited.
Here is a set of activities that usually need to be performed:
| Activity | Description | Methods to Speed up the Process |
|---|---|---|
| Change Control | The process of managing and documenting changes made to the system. It ensures changes are reviewed, approved, implemented, and validated. | Use template forms to standardize and speed up documentation. |
| Security Risk Assessment (If adding/changing cybersecurity features/functions) |
Evaluating potential security vulnerabilities introduced or affected by the software change. | Utilize automated vulnerability scanning tools. Maintain a security standards checklist that any change must adhere to. |
| Design Review | Formal review of design outputs to ensure they meet design input requirements. | Hold a single design review to discuss, review and approve all updated documentation. |
| Design Verification (limited to changes) |
Process of ensuring the software meets the specified design inputs. This involves testing, regression testing, and deciding when tests are needed. | Automate the testing processes using continuous integration (e.g., we like GitHub Actions). Maintain a library of regression tests that can be run as needed. Ensure tests are modular to allow easy modification/addition. |
| Document Control | Managing and maintaining all formal documents to ensure they're up-to-date, approved, and available to all relevant parties. | Implement a document management system with version control. Use electronic signatures to speed up review/approval processes. |
| Labeling | The software ‘label’ must be updated to reflect the new version | Have a standard process (i.e., release checklist) that includes a task to update the label. |
In general, regardless of the release type and given the amount of documentation work required, it’s usually not economical to release the software every week or even every month. Instead, it usually makes sense to lump together more changes so that they can be evaluated together and properly documented.
