EUDAMED requires four EU-MDR identifiers in the same record, and they are not interchangeable. The Basic UDI-DI groups a device family, the UDI-DI identifies the device model, the UDI-PI identifies the production unit, and the EUDAMED-DI replaces the Basic UDI-DI for legacy devices placed on the market under the MDR Article 120 transitional regime. This page disambiguates all four, with the citations and the side-by-side comparison the EUDAMED submission record needs. EUDAPrep does not issue UDIs of any kind; the four UDI issuing entities and the manufacturer’s own labelling system do that work. The page below is the operator’s map of the identifier landscape.
The complete UDI on a device carrier comprises a UDI-DI (static, device-model identifier) plus a UDI-PI (dynamic, production identifier). The Basic UDI-DI sits one level above as the device-family grouping key, and the EUDAMED-DI replaces it for legacy devices under Regulation (EU) 2024/1860.
What “UDI” actually means
UDI stands for Unique Device Identification. Under MDR Article 27 of Regulation (EU) 2017/745 and IVDR Article 24 of Regulation (EU) 2017/746, the UDI is the unique numeric or alphanumeric code that identifies a specific medical device or in-vitro diagnostic placed on the EU market. The system is not an EU invention: it implements the IMDRF UDI Application Guide internationally, with the EU’s particular hierarchy layered on top.
In the EU every UDI on a device carrier resolves to two components, the UDI-DI and the UDI-PI, and every UDI-DI traces upward to a Basic UDI-DI in the EUDAMED record. Devices on the market before the MDR took effect (legacy devices on extended certificates under MDR Article 120) use an EUDAMED-DI instead of a Basic UDI-DI; Regulation (EU) 2024/1860 introduced that mechanic for the legacy cohort, which has no original Basic UDI-DI to fall back on. The EU shape differs from the FDA’s UDI rule (21 CFR 830, GUDID).
The EU keeps its UDI records in EUDAMED under EC governance; the United States keeps its records in the FDA’s GUDID; the United Kingdom and other markets maintain national registers in parallel. This page covers the EU UDI structure only.
Basic UDI-DI: the device-family grouping key
The Basic UDI-DI is the device-family parent identifier under MDR Article 27(2). One Basic UDI-DI groups one or more UDI-DIs that share intended purpose, risk class, essential design and manufacturing characteristics, and (where applicable) name or trade name, per MDCG 2018-1 Rev. 4 §3.2. The grouping is conceptual: the Basic UDI-DI does not appear on the device label, the device itself or the AIDC carrier. It surfaces in the Declaration of Conformity, on the EU certificate, in the Annex II technical documentation and, most consequentially, as the top-level key for the device record in EUDAMED.
Issuing-entity formats for the Basic UDI-DI differ by entity. GS1 issues it as a Global Model Number (GMN) per the GS1 General Specifications; HIBCC and ICCBBA each carry their own Basic UDI-DI structure; IFA’s German PZN-aligned format completes the four. The manufacturer chooses one issuing entity for the device family and stays with it: switching mid-stream requires re-issuing every UDI-DI underneath. The choice is the load-bearing one for the rest of the UDI work; the structural rules, MDCG 2018-1 Rev. 4 grouping criteria and the EUDAMED validation walkthrough sit on the dedicated Basic UDI-DI assignment page.
The Basic UDI-DI is the unit at which the EU certificate is issued in the Class IIa-and-above regime: one Basic UDI-DI, one certificate, with the certificate naming the underlying UDI-DIs. A Basic UDI-DI assigned to too narrow a slice multiplies certificates; one assigned to too broad a slice can fail Notified Body review on lack of design coherence.
UDI-DI: the device-model identifier
The UDI-DI sits beneath the Basic UDI-DI as the static identifier for a device model, issued by the manufacturer’s chosen UDI issuing entity (GS1 GTIN, HIBCC LIC-based identifier, ICCBBA ISBT-128 identifier, or IFA PZN) per MDR Annex VI Part C. One UDI-DI per device model, with at least one UDI-DI under every Basic UDI-DI. The UDI-DI appears on the device label and on every higher level of packaging, in both AIDC (machine-readable) and HRI (plain-text) form. The (01) GS1 Application Identifier in a Data Matrix on a device label carries the GTIN that is the UDI-DI under GS1 syntax.
The UDI-DI is the EUDAMED record’s per-model anchor: each UDI-DI in EUDAMED carries its risk class, EMDN code, applicable legislation, labelling fields and the package-level configuration. MDCG 2018-1 Rev. 4 §4.1 sets out the structural rules; the GS1 GSCN-23-070 clarification distinguishes Basic UDI-DI (a GMN under GS1) from UDI-DI (a GTIN).
Software as a medical device follows MDCG 2018-1 Rev. 4 §6.5.2: a UDI-DI is assigned at the system level, with a new UDI-DI on a major software revision and a new UDI-PI on every other revision. The rule catches first-time SaMD manufacturers who try to UDI per module.
Per MDR Annex VI Part C 3.9, a new UDI-DI is required when any of these change for a device model:
- Name or trade name of the device.
- Product version or model designation.
- Addition of, or change to, “For single use only” labelling.
- Addition of, or change to, sterile-packed status.
- Addition of, or change to, the “Sterilization required before use” designation.
- Quantity of devices in a package.
- Important warnings or contraindications declared in the labelling.
The seven triggers are exhaustive: changes outside this list do not require a new UDI-DI.
UDI-PI: the production identifier
The UDI-PI is the dynamic component of the UDI: the production-batch identifier. Per MDR Annex VI Part C, the UDI-PI carries one or more of the lot or batch number, the serial number, the manufacturing date, the expiry date and, for software, the software version or identification. It changes with each lot or production unit and is the only component of the UDI carrier that varies between two physically identical devices.
The UDI-PI is generated by the manufacturer’s labelling or ERP system, not by the UDI issuing entity. GS1, HIBCC, ICCBBA and IFA each provide the company prefix and the AIDC standard the manufacturer’s system uses, but the UDI-PI string itself comes out of the production-control workflow. This is the structural point that distinguishes the UDI-PI from every other identifier on this page: it is the only one that is not issued.
Under GS1 syntax, a complete UDI carrier on a device label appears as a sequence of GS1 Application Identifiers concatenated in a Data Matrix:
(01)05012345678900(10)LOT12345(17)260601(21)SN98765Reading left to right: (01) is the GTIN, the GS1 representation of the UDI-DI; (10) is the lot identifier (LOT12345); (17) is the expiry date in YYMMDD format (1 June 2026); (21) is the serial number (SN98765). A German-market Class IIa surgical instrument with this carrier would surface in EUDAMED under the GTIN as its UDI-DI, with the lot, expiry and serial declared as labelling attributes; the UDI-PI is not registered batch-by-batch in EUDAMED but is declared at the field level on the UDI-DI record.
For active implantable devices the UDI-PI must include the serial number per MDR Annex VI Part C; for sterile devices it must include the lot or serial. The granularity is a labelling-system design choice the manufacturer makes once and applies consistently across the portfolio.
Side-by-side: Basic UDI-DI vs UDI-DI vs UDI-PI vs EUDAMED-DI
| Identifier | What it is | Issued or generated by | Required on physical device? | Where it appears in EUDAMED | Primary citation |
|---|---|---|---|---|---|
| Basic UDI-DI | Device-family grouping key | Issued by a UDI issuing entity (GS1 GMN, HIBCC, ICCBBA or IFA) | No (not on the label, device or AIDC carrier) | Top-level key for the device record in the UDI/Devices module; named on the EU certificate, DoC and Annex II file | MDR Article 27(2); MDCG 2018-1 Rev. 4 §3.2 |
| UDI-DI | Device-model identifier (static) | Issued by a UDI issuing entity (GS1 GTIN, HIBCC LIC, ICCBBA, IFA PZN) | Yes (on the label and every higher packaging level, in AIDC and HRI form) | One record per device model under each Basic UDI-DI, with risk class, EMDN code, labelling and packaging fields | MDR Annex VI Part C; MDCG 2018-1 Rev. 4 §4.1 |
| UDI-PI | Production identifier (lot, serial, manufacturing date, expiry, software version) | Generated by the manufacturer’s labelling or ERP system per batch or unit | Yes (variable component of the UDI carrier on the label) | Declared as labelling attributes against the UDI-DI; not registered batch-by-batch | MDR Annex VI Part C; EC UDI helpdesk |
| EUDAMED-DI | Legacy-device identifier (replaces Basic UDI-DI for MDD, AIMDD and IVDD devices on extended certificates) | Assigned within EUDAMED for legacy devices | No | Fills the Basic UDI-DI slot for legacy-device records | Regulation (EU) 2024/1860; MDR Article 120 |
| Master UDI-DI (special case) | Group identifier for highly individualised devices (contact lenses, spectacle frames and lenses, reading spectacles) | Issued under the Master UDI-DI scheme | No | One Master UDI-DI per group, in place of a device-by-device UDI-DI count | Commission Delegated Regs. (EU) 2023/2197, 2025/788, 2025/1920; MDCG 2024-14 Rev. 1 |
The Master UDI-DI is in scope only for contact lenses and spectacles. Manufacturers outside those categories ignore the row.
UDI carrier: HRI, AIDC, GS1 Application Identifiers, and direct marking
The UDI carrier is the physical representation of the UDI on the device label or, for reusable devices, on the device itself. MDR Annex VI Part C requires two parallel forms: AIDC (Automatic Identification and Data Capture, machine-readable) and HRI (Human-Readable Interpretation, plain-text). The AIDC is typically a GS1 Data Matrix, an HIBCC barcode or a linear GS1-128 barcode; the HRI is the same data printed legibly alongside.
Under GS1 syntax, the UDI carrier uses GS1 Application Identifiers (AIs) to delimit each data element. The five most common on a medical-device label are:
- (01): GTIN, the GS1 representation of the UDI-DI.
- (10): lot or batch number.
- (11): manufacturing date (YYMMDD).
- (17): expiry date (YYMMDD).
- (21): serial number.
The GTIN under (01) is the UDI-DI; the other AIs make up the UDI-PI. HIBCC and ICCBBA use their own delimiter syntaxes, and IFA aligns with the German PZN convention; the underlying structure (one DI plus a variable PI bundle) is the same.
Direct marking (Direct Part Marking, DPM) applies to reusable devices intended to be sterilised and reused, laser-etched or dot-peened directly onto the device per MDR Annex VI Part C. The direct-marked UDI is in addition to the UDI carrier on the packaging, not in place of it. For single-use Class I and IIa devices packaged individually at the lowest level, a Unit-of-Use DI mechanism applies so that the lowest packaging level carries a UDI-DI even where the device itself does not.
EUDAMED-DI: the legacy-device identifier under Reg. 2024/1860
The EUDAMED-DI is the identifier assigned within EUDAMED for legacy devices: devices placed on the EU market under the former Medical Devices Directive (93/42/EEC, MDD), the Active Implantable Medical Devices Directive (90/385/EEC, AIMDD) or the In Vitro Diagnostic Medical Device Directive (98/79/EC, IVDD), and continuing on extended certificates under MDR Article 120 transitional arrangements. These devices have no original Basic UDI-DI because they pre-date the MDR UDI obligations; Regulation (EU) 2024/1860 introduced the EUDAMED-DI to fill the parent-identifier slot in the EUDAMED record.
Mechanically, the EUDAMED-DI is generated by EUDAMED itself when the legacy device record is created, rather than issued by an external UDI issuing entity. It carries no implication that the device has a UDI carrier on its label: legacy devices typically do not, and the regulation does not retro-fit the UDI carrier obligation onto them. The EUDAMED-DI exists solely so that the EUDAMED record has a parent key for the legacy device, in the same data slot the Basic UDI-DI would otherwise occupy.
The deadline that drives the EUDAMED-DI mechanic is 28 November 2026, the date from which legacy devices on extended certificates must be in EUDAMED, per Commission Decision (EU) 2025/2371 and the 12-month transition under MDR Article 123(3). The new-device deadline of 28 May 2026 is separate and uses the regular Basic UDI-DI path. See the deadlines page for the legal-text walkthrough of both dates.
Where each identifier appears in EUDAMED
Each identifier surfaces in a specific EUDAMED slot.
The Basic UDI-DI is the top-level key for the device record in the UDI/Devices module. The EUDAMED public search at webgate.ec.europa.eu/eudamed/public.html lets any third party look up a Basic UDI-DI. The same identifier appears in the Certificates module on each EU certificate the Notified Body issues, and in the Actor module via the SRN linkage to the economic operator.
The UDI-DI appears once per device model beneath its Basic UDI-DI. Each UDI-DI record carries its risk class, EMDN code, applicable legislation (MDR or MDD/AIMDD/IVDD), labelling languages, packaging-level configuration and the link to the relevant certificate.
The UDI-PI is declared at the field level on the UDI-DI record, not as a separate record. The labelling-attribute fields specify which PI components apply (lot, serial, manufacturing date, expiry, software version). EUDAMED does not hold per-batch PI values; those live on the labels and in the manufacturer’s traceability system.
The EUDAMED-DI replaces the Basic UDI-DI slot for legacy device records and otherwise follows the same data shape, per Regulation (EU) 2024/1860. The current production XSD encodes all four identifier slots and their cross-field business rules at schema version v3.0.30 / platform v2.27.0.
Which identifiers do I need? UDI requirements by device class
Applicability depends on the device class and on whether the device is new under the MDR or legacy under the Article 120 regime. Custom-made devices are exempted from the UDI requirements under MDR Article 27(1); every other class follows the matrix below.
| Device class | UDI-DI required? | Basic UDI-DI required? | EUDAMED-DI applicable? |
|---|---|---|---|
| Class I (MDR-regulated) | Yes | Yes | No (use Basic UDI-DI) |
| Class IIa | Yes | Yes | No (use Basic UDI-DI) |
| Class IIb | Yes | Yes | No (use Basic UDI-DI) |
| Class III (including implantables) | Yes (UDI-PI must include serial number for active implantables, per Annex VI Part C) | Yes | No (use Basic UDI-DI) |
| Legacy (MDD / AIMDD / IVDD under Article 120) | Where present on label, declared; not retro-fitted | No | Yes (replaces Basic UDI-DI per Reg. 2024/1860) |
Software placed on the market as a medical device follows the matrix at its declared risk class, with the UDI assigned at the system level per MDCG 2018-1 Rev. 4 §6.5.2. Contact lenses and spectacles use the Master UDI-DI scheme in place of a device-by-device UDI-DI count, per the Commission Delegated Regulations cited in the §5 table.
The matrix sets the identifier floor only. EMDN code, language-specific labelling and package configuration are required on the UDI-DI record at submission regardless of class; those belong to the record-completeness scope rather than the identifier-applicability scope.