Basic UDI-DI vs UDI-DI: the device-family identifier explained

Few topics confuse newcomers to EU medical-device regulation more than the UDI family of identifiers. Basic UDI-DI, UDI-DI, UDI-PI — they sound interchangeable, but each does a distinct job, and getting them straight is essential for registering devices correctly in EUDAMED.

As of June 2026, MD Atlas has indexed 1,020,930 devices from EUDAMED. That number is an indexed subset of the public data rather than the complete device population, but it is more than enough to see how the UDI hierarchy organises a portfolio. You can browse the indexed devices here. (Every figure in this article links to the live search that produces it.)

The three identifiers, briefly

The Unique Device Identification system, defined under the Medical Device Regulation (EU) 2017/745, has three layers:

• Basic UDI-DI — the device family identifier. It groups devices that share the same intended purpose, risk class, and essential design and manufacturing characteristics.
• UDI-DI — the device-variant identifier. It identifies one specific model/configuration: a particular size, sterile vs non-sterile, and so on.
• UDI-PI — the production identifier. It carries the variable data printed on the label: lot or batch number, serial number, manufacture and expiry dates.

A useful mental model: Basic UDI-DI is the "product line", UDI-DI is the "SKU", and UDI-PI is the "specific unit on the shelf".

Why the Basic UDI-DI exists

The Basic UDI-DI is the entry point for regulatory documentation. It is the key under which certificates, declarations of conformity, and the Summary of Safety and Clinical Performance are associated. It deliberately does not appear on the device label or packaging — it is a database and documentation construct, not a scanning identifier.

This matters because it is the level at which regulators think about a device. When a notified body certifies a family, or when a manufacturer files technical documentation, the Basic UDI-DI is the anchor. One Basic UDI-DI can sit above many UDI-DIs: a single surgical-instrument family might span dozens of sizes, each with its own UDI-DI but all sharing one Basic UDI-DI.

Why the UDI-DI exists

The UDI-DI is the identifier that actually appears, encoded, on the device. It is issued under an accredited issuing entity — GS1, HIBCC, ICCBBA or IFA — and is the machine-readable key a hospital scans at the point of use. Because it identifies a specific variant, it is also the level at which most traceability, recall, and stock-management work happens.

The relationship is strictly hierarchical: every UDI-DI belongs to exactly one Basic UDI-DI, but a Basic UDI-DI typically covers several UDI-DIs. If you are trying to assess a manufacturer's portfolio, counting Basic UDI-DIs tells you how many families they market; counting UDI-DIs tells you how many variants.

How this shapes registration and classification

Classification under the MDR happens at the family level, which is exactly why the Basic UDI-DI bundles devices of the same risk class. You cannot mix a Class IIa and a Class III device under one Basic UDI-DI, because their conformity routes differ. For anyone preparing a registration, this is the practical rule: the Basic UDI-DI is the unit of regulatory truth, and the UDI-DIs hanging beneath it inherit that family's classification and certification context.

When you explore devices in practice, the hierarchy becomes visible. From a manufacturer's record you can move to their devices and see how variants cluster into families; from a single device you can trace back up to its Basic UDI-DI and across to the certificates that cover it. You can also narrow the device search by characteristics to see how a family's variants are distributed.

Getting it right the first time

The most common registration mistakes come from confusing these levels: putting production data where variant data belongs, splitting one family into multiple Basic UDI-DIs, or assuming a UDI-DI alone is enough to describe a device's regulatory standing. Keep the hierarchy in mind and the model stays clean:

• One Basic UDI-DI per family (documentation + certificates).
• Many UDI-DIs beneath it (the variants on the label).
• A UDI-PI for each production run (the variable data).

Master that structure and EUDAMED stops looking like an arbitrary forest of codes and starts reading as what it is: a precise, hierarchical map of the EU device market — one you can navigate from family, to variant, to the certificate that keeps it on the market.