A UDI under MDR Article 27 is a structured identifier made of two distinct parts. The UDI-DI — the device identifier — is the static element. It is unique to the manufacturer and to a specific version or model of the device at a defined packaging level, and it does not change from one unit to the next. The UDI-PI — the production identifier — is the variable element. It identifies the specific unit of production and is composed, as applicable to the device, of the lot number, the serial number, the software identification, the manufacturing date, and the expiry date. Together UDI-DI plus UDI-PI form the full UDI carried on the label and on higher packaging levels under Annex VI Part C. The UDI-DI answers "what is this device." The UDI-PI answers "which unit of it."

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • The UDI-DI is the static device identifier. One UDI-DI per device model, per packaging level, per manufacturer. It does not change from unit to unit.
  • The UDI-PI is the production identifier. It identifies the specific production unit and is composed of one or more of: lot number, serial number, software identification, manufacturing date, expiry date.
  • Which UDI-PI elements apply depends on the device type and on the rules of the chosen issuing entity, framed by Annex VI Part C of MDR.
  • UDI-DI and UDI-PI together make the full UDI carried on the label. The Basic UDI-DI, defined in Article 2(15), sits above both as the grouping identifier for a device family and is not carried on the label.
  • Only the UDI-DI (and the Basic UDI-DI) flow into the UDI database inside EUDAMED. UDI-PIs are not registered as individual entries — they live on the physical unit and in the manufacturer's traceability records.

Why the two-part structure exists at all

A founder reading Annex VI Part C for the first time might wonder why the Regulation splits the UDI into two pieces instead of assigning one long serial number per unit. The answer is that the two parts do two different jobs, and collapsing them would defeat both.

A hospital stockroom needs to know, when a product arrives, what it is — which model, which variant, which packaging configuration. That is a question about identity, not about individuality. One answer serves every unit of the same model. Storing that answer once per unit would be waste. The UDI-DI exists to carry the identity question once and let it be reused across every unit of the model.

A recall, by contrast, needs to know which specific units are affected — which lots went to which distributors, which serial numbers are in which clinics, which software versions are running where. That is a question about individuality, not identity. The UDI-PI exists to carry the individuality question on each unit.

The result is that a single scan of a UDI carrier tells a downstream system two things at once: what is this device, and which production unit of it is this. That is the traceability architecture MDR Article 27 is built around, and it is why the two components are defined separately in Annex VI Part C.

Definitions, drawn from Annex VI Part C

Annex VI Part C of Regulation (EU) 2017/745 is the source text for both definitions. Paraphrased from the Annex:

UDI-DI — the unique numeric or alphanumeric code specific to a model of device and that is also used as the "access key" to information stored in the UDI database. The UDI-DI is manufacturer-specific and model-specific. Each distinct packaging level of a given model receives its own UDI-DI.

UDI-PI — the numeric or alphanumeric code that identifies the unit of device production. The different types of UDI-PI include serial number, lot number, software identification, and manufacturing or expiry date, or both types of date. The applicable PI elements depend on the device.

Sitting above both is the Basic UDI-DI, defined in MDR Article 2(15) as the primary identifier of a device model and the main access key for information stored in the UDI database. One Basic UDI-DI can group many UDI-DIs (one per variant or packaging level), and each UDI-DI can be carried by many physical units, each with its own UDI-PI.

If the companion post What is UDI? uses the tree metaphor — Basic UDI-DI as the trunk, UDI-DIs as the branches, UDI-PIs as the leaves — this post is the close look at the branches and the leaves.

What the UDI-DI identifies

The UDI-DI identifies a device model at a specific packaging level, assigned by a specific manufacturer, under the rules of a specific issuing entity.

Three things matter about that sentence.

Model-specific. If two devices are different models — different intended purpose, different variant, different essential characteristics at the level the issuing entity requires a new code — they get different UDI-DIs. A change to the device that falls into the categories enumerated in Annex VI Part C (change in name, change in version, change in labelling affecting identification, change in intended purpose, and others) triggers a new UDI-DI.

Packaging-level-specific. The same physical device at unit level, at inner-pack level, at carton level, at pallet level — each packaging level gets its own UDI-DI. A box of twenty single-use devices has a UDI-DI for the individual unit and a separate UDI-DI for the box. This is not duplication; it is how scanners at different points in the supply chain see the right identity for the object they are actually scanning.

Manufacturer-specific. UDI-DIs are assigned under the manufacturer's prefix with the chosen issuing entity (GS1, HIBCC, ICCBBA, or IFA). No two manufacturers can issue the same UDI-DI because the manufacturer prefix is baked into the code.

The UDI-DI does not change between units of the same model at the same packaging level. Ten thousand units shipped in a year from the same model share the same UDI-DI. What distinguishes them is the UDI-PI.

What the UDI-PI identifies

The UDI-PI identifies the specific unit of production. It is the variable part of the UDI — different on different units of the same model — and its composition depends on the device type.

Annex VI Part C enumerates the PI elements. The applicable combination depends on the device and on the rules of the issuing entity:

  • Lot (batch) number. Used where devices are manufactured in batches and traceability is to the batch rather than the individual unit. Typical for single-use sterile devices, consumables, reagents.
  • Serial number. Used where individual units are tracked individually. Typical for implants, capital equipment, reusable devices where per-unit traceability is required.
  • Software identification. For software that is itself a medical device, the software version identifier serves as the UDI-PI. A new software version is a new UDI-PI (and, under the Annex VI Part C change rules, may also require a new UDI-DI).
  • Manufacturing date. Used where the date of manufacture is the relevant traceability anchor.
  • Expiry date. Used where the device has a defined shelf life and the expiry date is part of the unit-level traceability.

A single UDI-PI can be composed of more than one of these elements. A sterile single-use device may carry lot number plus expiry date as its PI. A reusable implant may carry serial number plus manufacturing date. A software product may carry software identification only.

The manufacturer does not pick the PI elements freely. The applicable elements are governed by the device type, by the rules of the issuing entity (GS1 Application Identifiers, HIBCC data structures, etc.), and framed by what Annex VI Part C requires for traceability of that device category.

When a UDI-PI is required — and when it is not

Not every device in every configuration requires every possible PI element. Annex VI Part C and the issuing entity rules together determine which PI elements are mandatory for a given device.

As a general reading:

  • Devices with a defined shelf life carry an expiry date element.
  • Devices manufactured in batches carry a lot number element.
  • Devices tracked individually — notably implantables and reusable capital equipment — carry a serial number element.
  • Software medical devices carry a software identification element.
  • Devices where the manufacturing date is the relevant anchor carry a manufacturing date element.

Devices that are not manufactured in lots, have no expiry, have no serial individuality, and do not contain software would in principle have no applicable PI elements — but in practice, for physical devices placed on the EU market under MDR, at least one PI element nearly always applies because at least one of lot, serial, or manufacturing date is used for traceability.

The practical guidance for a startup is to work with the chosen issuing entity and the Notified Body to document, for each device, which PI elements apply and why. The decision is part of the technical documentation and must be internally consistent with the labelling, the IFU, and the PMS plan.

How UDI-DI and UDI-PI appear on the label

Annex VI Part C specifies that the UDI carrier — the physical or digital representation of the UDI — must appear on the label of the device and on all higher levels of packaging. The carrier is typically a linear barcode (often GS1-128) or a two-dimensional data matrix (often GS1 DataMatrix), though other AIDC technologies are permitted. Human-readable interpretation of the UDI must accompany the machine-readable carrier, unless space constraints are justified.

On the label, the UDI-DI and the applicable UDI-PI elements appear together inside one carrier, encoded according to the chosen issuing entity's rules. A GS1 carrier, for example, uses Application Identifiers (AIs) to mark each element: AI (01) for the GTIN that serves as the UDI-DI, AI (10) for the batch/lot, AI (21) for the serial number, AI (11) for manufacturing date, AI (17) for expiry date, AI (235) and related AIs for software identifiers. HIBCC uses a different syntax with its own data structures. The result in all cases is a single scan that yields the full UDI — identity plus individuality — as one parseable string.

For reusable devices, Annex VI Part C requires direct marking of the UDI on the device itself in addition to the label, subject to the exceptions set out in the Annex. The direct marking must be permanent, readable after cleaning and reprocessing, and — where possible — both machine-readable and human-readable.

The Basic UDI-DI does not appear on the label. It lives in the technical documentation, on the declaration of conformity, on the Notified Body certificate where applicable, and in the UDI database. This is a persistent source of confusion: the identifier that is most important for regulatory documentation is the one that is never printed on the product.

How UDI-DI and UDI-PI flow to EUDAMED

The UDI database inside EUDAMED, established by MDR Article 28, holds the Basic UDI-DI and the UDI-DI together with the Annex VI Part B data elements. The UDI-PIs do not flow into the database as individual entries.

This asymmetry is often misread. A founder reading Articles 27 to 29 sometimes assumes that every lot number and every serial number needs to be uploaded to EUDAMED. It does not. EUDAMED holds the regulatory identity of the device model. The production identifiers live on the physical unit and in the manufacturer's own traceability system — ERP, batch records, device history records — not in EUDAMED.

What flows into EUDAMED is the UDI-DI (and the Basic UDI-DI above it) with the full Annex VI Part B dataset: risk class, manufacturer details, SRN, Notified Body where applicable, IFU URLs, presence of substances of concern, clinical investigation information, and the rest of the fields. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 governs the detailed functioning of EUDAMED including how UDI-DI submissions are made, corrected, and accessed.

The practical consequence is that a startup builds and maintains two distinct data layers. One is the EUDAMED layer — UDI-DI and Basic UDI-DI with Annex VI Part B data, submitted once per model per packaging level and kept current. The other is the internal traceability layer — UDI-PIs mapped to lots, serial numbers, distribution records, complaint handling, and vigilance. Both layers must agree on the UDI-DI, because that is the link between the database entry and the physical units in the field.

Common confusions

A handful of misreadings about UDI-DI and UDI-PI appear on almost every first project.

"The UDI is one number." It is a structured identifier combining UDI-DI and UDI-PI. Scanning the carrier returns both.

"The UDI-DI changes per unit." No. The UDI-DI is fixed for the model at a given packaging level. It is the UDI-PI that varies.

"We only need the UDI-DI; the UDI-PI is optional." The applicable UDI-PI elements are governed by Annex VI Part C and the issuing entity rules. For practically every physical device on the market, at least one PI element is required.

"The Basic UDI-DI is printed on the label." It is not. The Basic UDI-DI lives in the documentation and in the database. What is printed on the label is the UDI — UDI-DI plus UDI-PI elements.

"We submit UDI-PIs to EUDAMED." No. EUDAMED holds the UDI-DI and the Basic UDI-DI with Annex VI Part B data. UDI-PIs stay with the unit and the internal traceability system.

"A new lot needs a new UDI-DI." A new lot needs a new UDI-PI (the lot number) but shares the UDI-DI of the model. A new UDI-DI is triggered only by the changes enumerated in Annex VI Part C — model change, version change, labelling change affecting identification, intended purpose change, and others.

The Subtract to Ship angle on UDI-DI and UDI-PI

The two-part structure of the UDI is a clean application case for the Subtract to Ship framework for MDR. The work that survives subtraction is finite and traceable to Annex VI Part C.

The real work is: decide, for each device, which UDI-PI elements apply and document the reason; allocate UDI-DIs at each relevant packaging level; encode UDI-DI and UDI-PI together in the carrier under the chosen issuing entity's rules; get the carrier onto the label and, where the device is reusable, onto the device itself under Article 27(4); make sure the UDI-DIs used on labels are the same UDI-DIs submitted to the UDI database; and make sure the internal traceability system can resolve any UDI-PI back to a specific production unit, lot, batch, or software release.

Everything else is a candidate for removal. Parallel UDI-PI schemes that duplicate what the issuing entity already provides, custom serial-number databases that mirror internal ERP data for no regulatory reason, "UDI readiness workshops" that do not end with concrete PI decisions per device, and speculative RFID or blockchain layers that are not grounded in Annex VI Part C do not belong in a startup's plan. If a proposed activity does not trace to Article 27, Annex VI Part C, or the issuing entity's rules, it comes out.

Reality Check — Do you know your UDI-DI and UDI-PI structure?

  1. For each device you plan to place on the EU market, can you state the UDI-DI at each relevant packaging level?
  2. For each device, can you state which UDI-PI elements apply — lot, serial, software identification, manufacturing date, expiry date — and why?
  3. Have you chosen an issuing entity and confirmed that your UDI-DI and UDI-PI encoding follows that entity's rules?
  4. Does your label carry the UDI-DI and UDI-PI elements together in a single machine-readable carrier with human-readable interpretation?
  5. For any reusable device, have you defined the direct marking of the UDI on the device itself?
  6. Do you know which of the Annex VI Part C change categories would trigger a new UDI-DI versus a new UDI-PI for your device?
  7. Does your internal traceability system resolve any UDI-PI back to the specific production unit it identifies?
  8. Are the UDI-DIs on your labels the same UDI-DIs submitted to the UDI database under Article 29?

If you cannot answer five or more of these cleanly, the UDI-DI and UDI-PI structure is not yet a solved workstream.

Frequently Asked Questions

What is the difference between UDI-DI and UDI-PI? The UDI-DI is the static device identifier: unique to the manufacturer and the model at a specific packaging level, and unchanged from unit to unit. The UDI-PI is the production identifier: variable, identifying the specific production unit through one or more of lot number, serial number, software identification, manufacturing date, and expiry date. Together they form the full UDI carried on the label.

Which UDI-PI elements does my device need? It depends on the device type and the rules of the chosen issuing entity, framed by Annex VI Part C. Single-use sterile devices typically use lot number plus expiry date. Implants and capital equipment typically use serial number. Software medical devices use software identification. Documentation of the chosen elements belongs in the technical file.

Does a new lot require a new UDI-DI? No. A new lot requires a new UDI-PI (the lot number), but the UDI-DI of the model stays the same. A new UDI-DI is triggered only by the change categories set out in Annex VI Part C — model change, version change, labelling change affecting identification, intended purpose change, and others.

Is the UDI-PI submitted to EUDAMED? No. EUDAMED holds the UDI-DI and the Basic UDI-DI together with the Annex VI Part B data elements. UDI-PIs live on the physical unit and in the manufacturer's own traceability records. Commission Implementing Regulation (EU) 2021/2078 governs the detailed functioning of EUDAMED.

How are UDI-DI and UDI-PI encoded on the label? Inside a single UDI carrier — typically a linear barcode or a 2D data matrix — using the encoding rules of the chosen issuing entity. GS1 uses Application Identifiers to mark each element (for example AI (01) for the GTIN as UDI-DI, AI (10) for lot, AI (21) for serial, AI (17) for expiry). Human-readable interpretation accompanies the machine-readable carrier.

What is the relationship between UDI-DI and Basic UDI-DI? The Basic UDI-DI, defined in MDR Article 2(15), is a higher-level grouping identifier for a device family sharing the same intended purpose, risk class, and essential design and manufacturing characteristics. One Basic UDI-DI can group multiple UDI-DIs (one per variant or packaging level). The Basic UDI-DI is the access key in the database and appears in the technical documentation, on the certificate, and on the declaration of conformity — but not on the label.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2(15) (definition of Basic UDI-DI), Article 27 (Unique Device Identification system), and Annex VI Part C (the UDI system, including definitions of UDI-DI and UDI-PI, the types of production identifiers, UDI carrier requirements, direct marking rules, and change categories that trigger a new UDI-DI). Official Journal L 117, 5.5.2017.
  2. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 laying down rules for the application of Regulation (EU) 2017/745 of the European Parliament and of the Council as regards the European Database on Medical Devices (Eudamed). OJ L 426, 29.11.2021.

This post is part of the EUDAMED, UDI and Registration category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The pillar post for this cluster is What is EUDAMED?. For questions about how UDI-DI and UDI-PI apply to your specific device architecture — particularly the choice of PI elements for mixed hardware-software products — read this post alongside What is UDI? and MDR Articles 27-29 UDI requirements decoded.