22 October 2026
Steven Byrne and Osman El-Koubani
You can get medical device software changes to market fast. But, as a medical device manufacturer, each change you make to your software must be implemented, tested, and documented properly. With the right approach, this process can be more straightforward than it seems. Here’s how.
Preparing to move fast
Your software changes need to be implemented and documented in a way that is robust, traceable, and compliant with the software maintenance and configuration management procedures specified in IEC 62304.
IEC 62304 has a reputation amongst engineers for being process-heavy and cumbersome. But it doesn’t need to be. By setting yourself up correctly, it’s possible to move fast within the IEC 62304 framework.
Let’s unpack how to do that.
Start with a clear picture of the change
Software changes can begin with product iteration, ongoing software maintenance, or post-market events. Changes may include new feature requests, planned model retraining, and regular management of vulnerabilities and Software of Unknown Provenance (SOUP) components. They may also arise in response to software defects, incident reports or model drift.
Regardless of the route, the scope and impact of the software change must be captured in a change request record in accordance with your change-management procedure. Your change-management procedure forms part of your quality management system (QMS) and should set out how proposed changes are assessed and approved.
It’s critical that these scope and impact statements are well-crafted and specific, as the information in the change request must align with the software changes your engineering team implements and releases. The scope and impact statements in the change request will inform any changes to software requirements, risk records, risk controls, software design and code implementation. They will also help define the software testing required to ensure that the change has been implemented and that the device’s function and safety are preserved.
Every change must be documented, whether it requires prior approval from your Notified Body or not, and whether it’s reportable to your Notified Body or not. Changes that are non-reportable or that do not require prior approval will still be subject to review on a sampling basis during surveillance. Ensuring that your change documentation is clear and complete will help minimise queries and rework during surveillance assessments.
Set up your engineering infrastructure
Testing and documenting software updates can get messy – fast. That’s why you may want to consider automating parts of this process.
Automating software development with continuous integration pipelines
For your software development, continuous integration (CI) pipelines are a way to run automatic checks when you make changes. They allow you to:
Automate the software build process
Run quality and security checks on your code
Deploy your software build to simulated environments
Execute software tests
Generate key software development artefacts, such as code analysis reports, test execution reports and release notes
Automating documentation
You can also make change documentation easier for your team. Consider implementing software platforms (commercial or built in-house) that allow you to:
Manage versions of your technical documents
Automate change histories
Ingest software development artefacts
Manage traceability between document artefacts
Align snapshots of the technical documentation to a given software release
Export these snapshots for Notified Body inspection
This tooling requires time and expertise to set up and maintain. However, it will save you from a lot of repetitive, time-consuming and manual work – and make it much easier to stay compliant. If you are serious about frequent changes, investment in the software development and technical documentation infrastructure is a must.
Streamline your testing with a risk-based approach
Testing your software changes is key. But how you do it is important.
Some engineering teams never go beyond basic functionality tests, while others mandate a full suite of software tests for every release. Neither approach is ideal. Instead, consider a risk-based approach to testing.
Software testing has two main aims:
Verifying that the update itself works
Testing whether the update has impacted anything else (‘regression testing’)
The first part (verifying the update itself) applies to all updates. The second part (regression testing) should be done in proportion to the risk of the update. The more complex the change, the higher the risk that it adversely affects the device’s operation, safety, or security.
It’s up to you to determine the level of risk, and therefore the level of testing that should be applied. Whatever your decision, it must be supported by a documented impact assessment and rationale for the chosen level of testing.
Keep your procedures and everyday practice aligned
With the frantic day-to-day pace of medical device development, there’s a risk that engineering teams begin to lose their rigour: testing is neglected, technical documentation falls by the wayside, or perhaps change control records fall out of sync with engineering artefacts and software versions.
While automation can help, ultimately, teams must be committed to upholding software maintenance plans and maintaining accurate records and traceable evidence of each software change. Insufficiently tested changes can introduce defects that harm patients and trigger costly field safety corrective actions. Gaps in records can lead to audit findings that take time and resources to resolve.
Four principles for managing frequent software releases
Getting the balance right
EU MDR is designed to allow you to update your software medical devices quickly and frequently after initial certification. However, it also mandates that you establish and follow robust change management and software development procedures to ensure device performance and patient safety.
By clearly scoping your changes, using automation in your engineering infrastructure, and taking a risk-based approach to testing, you can ease the process and keep shipping in a safe and compliant way.