UDI-DI Explained
The Unique Device Identifier (UDI) is a structured code that identifies a medical device and its production information. It has two mandatory components under MDR Article 27 and IVDR Article 24:
- UDI-DI (Device Identifier): a fixed code that identifies the specific device model, version, and configuration. It appears on the label and in EUDAMED. It does not change between production batches of the same device.
- UDI-PI (Production Identifier): a variable code that identifies the specific production unit: lot number, serial number, manufacturing date, expiry date, or software version. It changes with each production run.
The UDI-DI is the primary identifier used in EUDAMED device registration. When regulators or competent authorities query the database, they search by UDI-DI. Every device record in EUDAMED is anchored to a UDI-DI.
UDI-DIs are issued by the three Commission-recognized issuing entities: GS1 (using the GS1 Application Identifier 01 GTIN structure), HIBCC (using the Health Industry Bar Code format), and ICCBBA (for blood, cells, tissue, and human origin products). The choice of issuing entity does not affect EUDAMED. All three formats are accepted.
Basic UDI-DI
The Basic UDI-DI is a higher-level grouping concept introduced by MDR Annex VI Part C that appears in regulatory documentation but not on device labels. It is the key identifier used on the EU Declaration of Conformity and links all UDI-DI variants of a device to the same regulatory submission.
What the Basic UDI-DI groups
A Basic UDI-DI groups together all UDI-DIs that share the same intended purpose, risk class, and essential design and manufacturing characteristics. Devices that differ only in packaging configuration or unit of use, while remaining the same device in all clinically and regulatorily material respects, can share a Basic UDI-DI.
In practice, most straightforward devices have a one-to-one relationship between Basic UDI-DI and UDI-DI. The grouping mechanism matters most for portfolios with multiple pack sizes, single-unit versus multi-pack variants, or sterile versus non-sterile versions of the same device body.
Where it appears
The Basic UDI-DI appears on the EU Declaration of Conformity and in the EUDAMED device registration record. It does not appear on device labels, packaging, or shipping containers. This is a deliberate design: the Basic UDI-DI is a regulatory reference identifier, not a logistics or supply chain identifier.
Triggers for a New UDI-DI
MDR Annex VI Part C Section 3.9 specifies the changes to a device that require a new UDI-DI to be assigned. The formal regulatory standard is that a new UDI-DI is required whenever changes affect the identity or essential characteristics of the device. A change that meets this threshold means the existing UDI-DI can no longer be used for that configuration. EUDAMED treats the old and new as distinct devices.
The MDCG guidance document MDCG 2018-1 Rev. 4 provides the authoritative interpretation of these triggers, with worked examples for the cases that generate the most ambiguity.
Triggers that always require a new UDI-DI
- Device name or trade name change. A different name on the label means a different UDI-DI, even if the underlying device is physically identical.
- Change to labelled sterility. Moving from sterile to non-sterile (or vice versa) requires a new UDI-DI. The sterility status is a fundamental device characteristic.
- Change in single-use designation. A device relabeled from reusable to single-use, or the reverse, requires a new UDI-DI.
- Critical performance or safety characteristic change. Any change to a characteristic that is necessary for the device to perform its intended purpose safely. What constitutes "critical" is assessed against the device's risk analysis and essential requirements documentation.
- Version or model identifier change where the change reflects a new configuration with different characteristics. A version number change that is purely cosmetic and reflects no physical or performance change does not automatically require a new UDI-DI, but this determination must be documented in the change control record.
Changes that do not automatically require a new UDI-DI
- Changes to labeling text that do not alter the device identification (corrected translations, updated addresses, formatting changes)
- Changes to packaging artwork that do not affect device identification
- Manufacturing site changes, provided the device specification is unchanged
- Supplier changes for non-critical components, provided the device performance is unchanged
Grouping Hierarchy
A fully structured UDI hierarchy for a device portfolio has three levels, each serving a different regulatory function.
| Level | Identifier | Appears On | Changes When |
|---|---|---|---|
| Grouping | Basic UDI-DI | EU Declaration of Conformity, EUDAMED record | New DoC is required (new certificate or fundamental design change) |
| Device | UDI-DI | Label, packaging, EUDAMED record | Any Annex VI Part C Section 3.9 trigger applies |
| Production unit | UDI-PI | Label, individual packaging | Every production run (lot, serial, expiry, manufacturing date) |
Unit of Use DI
For devices where the packaging unit does not carry a label with a UDI-DI (individual surgical instruments within a kit, single cells from a strip of test cassettes), a Unit of Use DI can be assigned. This is an additional identifier at the individual-use level and is optional under MDR unless required by the device-specific regulation or the NB.
Common Grouping Errors
| Error | What Goes Wrong | Correct Approach |
|---|---|---|
| Single UDI-DI for multiple pack sizes | Accepted by EUDAMED but pack quantity field mismatch causes traceability failures during post-market surveillance queries | Different pack sizes of the same device get their own UDI-DI if they are sold separately. Same device, different quantity on the label, different UDI-DI. |
| Sharing a Basic UDI-DI across device classes | EUDAMED flags the record when certificate cross-reference covers different class devices under one DoC reference | Each risk class requires its own DoC and therefore its own Basic UDI-DI. Never group Class IIa and Class IIb devices under one Basic UDI-DI. |
| Assigning a new UDI-DI without updating the DoC | UDI-DI in EUDAMED references a Basic UDI-DI that does not appear on the current DoC; creates a compliance gap | UDI-DI changes and DoC updates are part of the same change control event. Process them together. |
| Using an internal part number as the UDI-DI | Not issued by a recognized issuing entity; EUDAMED validation fails | UDI-DIs must be issued by GS1, HIBCC, or ICCBBA. Internal part numbers are a parallel system with no EUDAMED validity. |
| Same UDI-DI for sterile and non-sterile versions | Sterility status is a hard trigger for a new UDI-DI; using the same one for both is a labeling non-compliance | Sterile and non-sterile variants of the same base device require separate UDI-DIs, even if the device body is identical. |
Relevant Guidance
The UDI framework under MDR is supported by a body of MDCG guidance that addresses the cases the regulation text leaves ambiguous. The following documents are the primary references for UDI-DI grouping decisions.
| Document | Topic | Key Sections for Grouping |
|---|---|---|
| MDCG 2018-1 Rev. 4 | Guidance on Basic UDI-DI and changes requiring new UDI-DI | Section 4 (Basic UDI-DI concept), Section 6 (change triggers), Annex with worked examples |
| MDCG 2022-7 | Questions and answers on the UDI system under MDR and IVDR | Q&A 12 (Basic UDI-DI grouping), Q&A 18 (version/model changes) |
| MDR Annex VI Part C | Regulatory text for UDI-DI assignment requirements | Section 3.9 (triggers for new UDI-DI), Section 3.10 (Basic UDI-DI definition) |
| MDR Article 27 / IVDR Article 24 | Legal basis for the UDI system under MDR and IVDR respectively | MDR Article 27 paragraphs 1 and 4; IVDR Article 24 for IVD-specific UDI obligations |
UDI-DI grouping is not a system configuration task. It is a series of regulatory judgments that must be made by someone with access to the device's design history, change control records, and intended use documentation. The EUDAMED record reflects those decisions. It does not make them. Getting the grouping right before registration avoids the far more painful process of correcting an incorrect UDI structure after certificates have been issued.