Expert knowledge for digital decisions

How are updates and significant changes assessed regulatory?

Short answer

Every update requires a documented change assessment that considers purpose, MDR qualification and class, risks, clinical evidence, usability, cybersecurity, testing, and UDI impacts. Whether a change is 'significant' depends on the regulatory context; MDCG 2020-3 Rev. 1 explicitly addresses legacy products in the transitional provision of MDR Article 120 and is not universally applicable to every MDR product.

Not the version number decides

An update is not regulatory significant solely because of a new major version number, nor is it automatically uncritical because it is labeled as a 'bug fix'. The content and potential impact are crucial. MDCG 2019-11 Rev. 1 requires that changes to function, purpose, essential design, and manufacturing characteristics be assessed to determine whether qualification as medical software or classification is affected.

A regulated change control process should at least answer the following questions:

Does the medical purpose, target population, user group, or clinical statement change?
Are new outputs, algorithms, data sources, interfaces, or operating platforms introduced?
Are new hazards introduced or existing risks and controls altered?
Is the existing clinical evidence still sufficient for the changed function?
What requirements, architecture, usability, and cybersecurity evidence are affected?
What regression tests and release criteria are necessary?
Do technical documentation, labeling, instructions for use, PMS, or UDI need to be updated?

UDI rules for software

MDR Annex VI Part C Number 6.5.2 requires a new UDI-DI when a change alters the original performance, safety, or purpose of the software or the interpretation of data. Examples mentioned in the MDR include new or modified algorithms, database structures, operating platforms, architectures, user interfaces, or interoperability channels. Minor revisions such as ordinary bug fixes, non-safety-related usability improvements, security patches, or efficiency improvements generally require a new UDI-PI and a manufacturer-specific version identifier according to Number 6.5.3, but not automatically a new UDI-DI.

Correctly classify 'Significant Change'

MDCG 2020-3 Rev. 1 specifies significant changes for legacy products utilizing transitional provisions under Article 120 MDR. The flowcharts provided there are intended for this specific status. For regularly MDR-certified products, change notification and involvement of the notified body depend on the applied conformity assessment procedure, the quality management system, and the conditions of the certificate, including Annex IX.

Release only after completed impact analysis

A change may only be released once the affected evidence has been updated, new or altered risk controls have been verified, and open anomalies have been assessed. Security updates may be urgent; this does not exempt regulatory documentation. A predefined emergency process allows for quick patches while still maintaining assessment, testing, communication, and traceability in full.

Example from practice

Replacing a library without changing functionality may trigger limited regression. A new algorithm that weights findings differently, however, affects data interpretation, clinical evidence, risk files, testing, and possibly the UDI-DI.

Key facts

Software UDI: MDR Annex VI Part C Number 6.5
New UDI-DI: For changes to performance, safety, purpose, or data interpretation
Legacy guideline: MDCG 2020-3 Rev. 1 on Article 120 MDR
Lifecycle guideline: MDCG 2019-11 Rev. 1, Section 8

Sources

All external claims are backed by traceable sources.

01
Verordnung (EU) 2017/745, Anhang VI Teil C Nummer 6.5 EUR-Lex / Europäische Union
02
MDCG 2019-11 Rev. 1 – Qualification and Classification of Software Medical Device Coordination Group / Europäische Kommission
03
MDCG 2020-3 Rev. 1 – Significant changes under Article 120 MDR Europäische Kommission