Making AI & SaMD changes under EU MDR: Part 2 - Class III

In our last post, we looked at Scarlet’s device-change criteria for Class IIa/IIb AI/Software as a Medical Device (AIaMD/SaMD). This week’s post looks specifically at how to approach changes for Class III.

Because they are high risk, Class III medical devices require more Notified Body oversight than Class IIa/IIb. That means that – for most changes to a Class III medical device – you must report them to your Notified Body and get prior approval before implementation.

What the regulations say

For Class III devices, two sets of EU MDR requirements apply. 

1. Changes to your QMS and device range: Substantial changes to your QMS or extensions to your device range must be reported to your Notified Body and receive prior approval before implementation (Annex IX, Section 2.4). This includes adding a Class III device to your QMS certificate, which will trigger a new application for conformity assessment, including a full technical documentation assessment.

2. Changes to your approved device: For changes to a Class III device already covered by a product certificate (known as an ‘approved’ device), Annex IX, Section 4.10 lays out clear rules. Changes require notification and prior approval where they could affect the safety and/or performance or the conditions prescribed for use, such as changes to the approved design, type, or claims made for the device, or additions to the intended purpose.

Reporting Class III changes

While the vast majority of Class III changes need to be reported to your Notified Body, there is a small set of changes that do not. 

These are minor changes that do not affect the General Safety and Performance Requirements (GSPRs), device design, performance specifications, conditions prescribed for use, or the intended purpose of the device (EU MDR Annex IX, Section 4.10).

When you deem a change non-reportable, you must document the change and include a clear justification for why it does not affect any of the elements identified in Annex IX, Section 4.10. Your Notified Body will review these justifications during surveillance audits.

For Class III AIaMD/SaMD:

Pitfalls to avoid 

As we laid out in the first post of our series on changes, it is the manufacturer’s responsibility under EU MDR Article 10(9) to categorise each planned change. 

A common pitfall in this process is to perform validation testing on a change and allow that testing to influence its category. For example, a manufacturer retrains an AI model, demonstrates through performance testing that the device performance has not been adversely affected, and concludes on that basis that the change is non-reportable. 

For Class III devices, the correct approach is to categorise the planned change a priori based on its nature and scope, before any verification, validation testing, or other performance assessment activities. Validation activities do not determine whether a change is reportable. In particular:

• Demonstrating comparable or improved performance does not convert a reportable change into a non-reportable change.

• The requirement to perform additional performance, usability, or risk analysis is an indicator that the planned change may affect safety or performance, not evidence that it does not.

In practice, the change must be categorised before it is validated. The validation supports approval of the change; it does not determine its category. A successful validation result alone is not enough to categorise a change as non-reportable.

Predetermined Change Control Plans

For Class III devices, the most powerful tool for accelerating the per-change pre-approval cycle is the Predetermined Change Control Plan (PCCP). A PCCP lets a manufacturer agree with its Notified Body, in advance, on what may change, how each change will be reviewed and validated, and how the change affects the benefit-risk profile of the device. Changes implemented strictly in accordance with an approved PCCP, and meeting the defined acceptance criteria, do not require approval prior to implementation. 

For software, which changes frequently, a PCCP converts what would otherwise be a series of longer approvals into a single, pre-agreed framework – the clearest route to moving quickly while remaining compliant.

Key takeaways

• The vast majority of Class III changes need to be reported to your Notified Body

• There is a small set of Class III non-reportable changes involving minor technical maintenance, accessory functionality, and UI adjustments

• Changes to Class III devices must be categorised before any validation testing, not after