How to handle incremental software changes during MDR certification?

Question

We are preparing our device for MDR certification but are struggling with the problem of incremental changes:
• We submitted our Technical Documentation (TD) for version 2.14 in August 2022.
• We add features approximately monthly under MDD/Article 120 and are now at version 2.17, performing incremental V&V.
• The notified body (NB) asks: Which exact version are you going to release? Provide the version number and TD for that version, along with a full V&V report.
• We respond: It depends on when you certify us, as we cannot stop the entire development flow based on the TD review speed.

I understand the NB needs a specific version and documentation, but this is challenging with a fast-moving software product. Are there any points from the MDR or MDCG that can be used as argumentation? We will struggle to complete a full V&V cycle within the NB's deadline.

Dr. Oliver Eidel · Accepted Answer

We follow a similar approach. We pick a version to submit for certification (e.g., v2.14), submit a full V&V report (which for us is the collection of all relevant test reports at that time), and continue developing new features. After certification, we provide summary documentation and impact assessments for changes made in subsequent versions. As long as those changes are assessed as non-significant, the NB typically does not require a new review. However, you do need to be careful about the changes you make between versions. If you want to avoid a new NB review, stick to minor tweaks, bug fixes, or cybersecurity updates, and group significant changes for periodic review.

Answer

We are in a similar situation and my understanding is that you should submit the specific version (e.g., v2.14) for full review and certification. Afterward, you can document changes up to your current version (e.g., v2.17), including impact assessments for those changes. If the notified body agrees that none of the changes are significant, the review should be brief. It's important that the Basic-UDI on the certificate remains unchanged between versions. This way, you avoid having to resubmit for each minor update. I'm also interested to hear more about others' experiences with their NBs.

Answer

We determined that moving from MDD to MDR (new risk class, new regulation) was a significant change, so we started a new major software version (e.g., from 1.12.0 to 2.0.0). We froze 2.0.0 and did not release it before certification. That was the version certified by the NB. After certification, we merged features from the MDD version into the MDR version, as long as those changes were assessed as non-significant, and released the updated version. This way, only the certified version is released initially, and subsequent (non-significant) changes do not require NB involvement.

Answer

We had a similar experience transitioning to MDR. We got our MDR clearance for a specific version (e.g., 2.x), then immediately after clearance submitted a design change, which took some extra months to get approved. In the meantime, we continued marketing the older MDD-certified version. Once the MDR version was cleared, we replaced the old version on the market. It is helpful to freeze a version for NB review and only release it after certification.

Answer

The idea is that for initial NB certification, you submit a fully documented device that is not yet on the market, so there are no ongoing changes during the assessment period. NB procedures are generally more suited for hardware, which doesn't evolve as quickly as software, so this can be a challenge for software products.

How to handle incremental software changes during MDR certification?

5 Answers

Keep reading

Experience navigating significant change notifications under MDR/IVDR for SaMD

Doing a Software Release in Compliance With IEC 62304

SGS (Belgium)