AI/ML SaMD change control: EU MDR, HSA, and PCCP compared

Why change control is the central AI/ML compliance problem

Hardware medical devices do not spontaneously change their behaviour after certification. AI/ML SaMD does — or at least, it can. Model retraining on new data, drift correction, architecture updates, new training datasets, and threshold adjustments all have the potential to alter the clinical output of a certified device. Regulators wrote change control frameworks before AI was commonplace, and the criteria do not always map cleanly onto software.

The practical consequence is that AI/ML SaMD teams face a recurring compliance question with every release cycle: is this change significant enough to require regulatory notification — and if so, to whom, in which market, with what documentation? Getting this wrong in either direction is costly: notifying unnecessarily delays releases; failing to notify when required is a post-market non-conformity waiting to be found in the next surveillance audit.

The EU MDR framework: MDCG 2020-3

MDCG 2020-3 (Guidance on significant changes regarding the transitional provision under Article 120 of the MDR) defines what constitutes a significant change. Although originally written for the MDD transition context, it is also the operative guidance for post-certification change control under EU MDR Article 54 — the provision requiring manufacturers to notify their NB of changes that could affect conformity.

MDCG 2020-3 defines a significant change as any modification that could affect the device's safety or performance to a degree that requires a new conformity assessment, or that changes the intended purpose or indications. It then provides examples — but these examples were drafted primarily with hardware in mind.

Applying MDCG 2020-3 to AI/ML changes

For AI/ML SaMD, the key question under MDCG 2020-3 is whether a change could affect the clinical performance — the accuracy, sensitivity, specificity, or clinical decision output — of the device in a way that exceeds what was validated and certified. The following categories require particular attention:

• Intended use or indications: Any extension to a new condition, patient population, anatomical site, or clinical setting is significant by definition. Adding a new diagnostic target to an imaging AI — even if the underlying architecture is unchanged — is a new intended purpose.
• Algorithm changes affecting clinical output: Changes to model weights, architecture, inference thresholds, or post-processing logic that produce measurably different outputs for the same inputs require assessment. The test is whether the clinical output could differ — not whether it typically does in practice.
• Training data scope: Retraining on data from a substantially different patient population (different demographics, different scanner types, different clinical settings) is a significant change if the original validation was not designed to cover that population.
• Input data format or type: Changes to what the model receives as input — new imaging modalities, additional laboratory parameters, different data preprocessing — affect what the algorithm is doing and require re-evaluation.
• Output interpretation: Changes to how clinical users interact with outputs — new risk scores, changed threshold displays, different flagging logic — may not change the model but can change clinical use patterns.

The decision tree: does this change require NB notification?

Comparison: EU MDR vs HSA CMP vs FDA PCCP

The three major frameworks for AI/ML SaMD change control share the same underlying concern — ensuring that post-market changes do not degrade clinical safety or performance — but differ significantly in architecture and in how much they can accommodate the continuous improvement reality of AI products.

What this means for EU-first AI/ML SaMD companies

The absence of a PCCP equivalent in EU MDR is a genuine operational constraint for AI/ML SaMD companies with continuous improvement cycles. Every significant algorithm change — even a well-validated, clearly beneficial retrain — requires NB notification and review, with associated delays. There is no mechanism to pre-approve a defined set of future changes the way FDA now allows.

The practical responses available to EU-certified AI/ML companies are:

• Pre-specify performance thresholds in the original technical file: This is the single most important step. Thresholds documented before certification allow future retraining to be assessed against a pre-approved baseline rather than requiring case-by-case NB dialogue.
• Design your change control SOP around the MDCG 2020-3 criteria: A documented, repeatable significance assessment process — run before every release — produces the audit trail that demonstrates compliant change management during NB surveillance audits.
• Batch non-significant changes: Minor updates that are individually non-significant can be implemented without NB notification. Accumulating multiple small improvements before a version release can reduce regulatory overhead.
• Engage the NB proactively on borderline changes: Many NBs will discuss a proposed change informally before a formal notification. This avoids surprise objections and can accelerate review when notification is required.

The change control record: what to document

Whether a change is assessed as significant or not, the change control record must be sufficient to demonstrate the assessment was performed rigorously. For AI/ML changes under EU MDR, the record should include:

• Change description: Precise specification of what changed — model architecture, training data, hyperparameters, inference logic, post-processing, thresholds. Version control references (git commits, dataset versions) should be linked.
• Significance assessment: Documented evaluation against each relevant MDCG 2020-3 criterion with explicit conclusion — significant or not significant — and the justification for that conclusion.
• Performance comparison: Pre- and post-change performance metrics on the validation dataset, compared against pre-specified acceptance thresholds. If thresholds were not pre-specified, explain why and document the alternative basis for assessment.
• Risk assessment update: ISO 14971 risk assessment reviewed and updated if the change introduces new hazards or modifies existing risk controls. Reference the specific risk file revision.
• IEC 62304 records: Software change request, change impact analysis, and verification records per the IEC 62304 change management requirements for your software safety class.
• NB notification: If significant — copy of notification submitted to NB, NB acknowledgement, and outcome of NB review. If not significant — explicit statement that NB notification was not required and why.