MDCG 2018-5 applies the EU UDI rules to standalone medical device software. Changes to performance, safety, data interpretation, the Basic UDI-DI or key identification details require a new UDI-DI; minor revisions such as routine bug fixes and security patches normally require a new UDI-PI.
Who this applies to
This guidance is for manufacturers of software that is commercially available on its own or itself qualifies as a medical device or IVD. It helps regulatory, software and quality teams decide how software versions fit into the EU Unique Device Identification system.
Software that merely forms part of another device is handled through the UDI of that device. Standalone medical device software is subject to the software-specific UDI rules in Annex VI of the MDR or IVDR.
The three identifiers do different jobs
Identifier
What it identifies
Typical software use
Basic UDI-DI
A regulatory family of devices with the same intended purpose, risk class and essential design and manufacturing characteristics
Links the family across certificates, declarations and technical documentation; it is not placed on the label
UDI-DI
A particular device and version/model identity
Changes when identification, traceability, performance, safety or interpretation is materially affected
UDI-PI
Production information for the particular instance or release
Identifies minor software revisions using the manufacturer's defined versioning method
Do not use these identifiers interchangeably. A patch-level release may change the UDI-PI without creating a new UDI-DI, while a larger change can require a new UDI-DI and, in some cases, a new Basic UDI-DI.
When software needs a new UDI-DI
A new UDI-DI is required when a modification changes the software's original performance, safety or interpretation of data. MDCG 2018-5 gives examples including new or modified:
algorithms;
database structures;
operating platforms or architecture;
user interfaces; and
interoperability channels.
The result depends on the impact, not the engineering label attached to the release. A team calling a change a “minor update” does not make it minor for UDI purposes.
A new UDI-DI is also needed when the Basic UDI-DI changes or when key identification information changes, including the name or trade name, version or model, critical warnings or contraindications, or the user-interface language. The broader rule is that a new UDI-DI is required whenever a change could cause misidentification or ambiguity in traceability.
When a new UDI-PI is enough
Minor software revisions require a new UDI-PI rather than a new UDI-DI. The guidance associates these with:
bug fixes;
usability improvements that are not safety-related;
security patches; and
operating-efficiency improvements.
The manufacturer must use a defined, manufacturer-specific way to identify these revisions. Keep the rationale showing why the release did not affect original performance, safety, data interpretation, intended purpose or the characteristics used to group the software.
What this means for you, practically
Every software change should be assessed through the quality system. The assessment should consider, in order:
Does the change affect qualification as medical device software?
Does it affect classification or intended purpose?
Does it change essential design or manufacturing characteristics and therefore the Basic UDI-DI grouping?
Does it affect performance, safety, data interpretation or identification and therefore require a new UDI-DI?
If none of those apply, is it a minor revision requiring a new UDI-PI?
Record the evidence used, the identifier decision, affected labelling and registrations, and the release in which the change takes effect. This prevents the UDI decision from becoming a late packaging or database task.
For the underlying grouping and change rules, read MDCG 2018-1. For the wider quality-system implementation, use MDCG 2021-19.
