UDI stands for Unique Device Identification. Under MDR Articles 27 to 29, every medical device placed on the EU market (other than custom-made and investigational devices) must carry a Unique Device Identifier assigned according to the rules of an issuing entity designated by the European Commission. The UDI consists of two elements: a UDI-DI (device identifier) that is unique to the device model, and a UDI-PI (production identifier) that identifies the unit of production — lot, serial number, software version, manufacturing date, or expiry date as applicable. Sitting above the UDI-DI 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. The UDI is the backbone of device traceability, EUDAMED registration, label content, and post-market surveillance under the MDR.

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

TL;DR

  • UDI is established by MDR Article 27. Every device other than custom-made and investigational must carry a UDI assigned under the rules of an issuing entity designated by the Commission.
  • A UDI is made up of a UDI-DI (fixed, unique to the device model and packaging level) and a UDI-PI (variable, identifying the production unit — lot, serial, software version, manufacturing date, expiry date).
  • The Basic UDI-DI is defined in MDR Article 2(15) as the primary identifier of a device model. It is the access key in the UDI database and the identifier that appears in the technical documentation, on the EU declaration of conformity, on certificates, and in the Summary of Safety and Clinical Performance.
  • The Commission has designated four UDI issuing entities for the EU: GS1, HIBCC, ICCBBA, and IFA. Manufacturers choose one and assign UDIs under that entity's rules.
  • UDI information is registered in the UDI database within EUDAMED under MDR Articles 28 and 29, with the data elements specified in Annex VI Part B. Commission Implementing Regulation (EU) 2021/2078 governs the detailed functioning of EUDAMED, including the UDI module.

You read Article 27 and wondered what any of it actually meant

A founder reads MDR Article 27 for the first time and finds a system that looks simple in concept and bewildering in detail. There is a UDI. There is a UDI-DI. There is a UDI-PI. There is a Basic UDI-DI, which sounds like it should be a simpler version but is actually a higher-level grouping identifier. There are four issuing entities to choose between, none of whose names (GS1, HIBCC, ICCBBA, IFA) mean anything to a first-time reader. There are obligations to carry the UDI on labels, on packaging, and in some cases directly on the device. There is a database to register it in, inside another system (EUDAMED) that is itself half-built. And somewhere in the middle of all of it is a startup trying to work out what it actually has to do before placing a device on the market.

This post is the orientation to UDI itself. It answers what UDI is, what the components mean, who assigns UDIs, how UDI connects to EUDAMED registration, what has to appear on labels versus in the database, how software is handled, how implementation is staged by risk class, and the misunderstandings founders reliably fall into. The pillar post for this whole cluster is What is EUDAMED?. Read it alongside this one.

What UDI is

UDI is short for Unique Device Identification. MDR Article 27(1) establishes a system that allows the identification and facilitates the traceability of devices, other than custom-made and investigational devices. The system is based on Unique Device Identifiers — UDIs — assigned by the manufacturer to each device before placing it on the market.

The Regulation is explicit about the three things the UDI system is designed to achieve. First, identification — each device model has an identifier that uniquely distinguishes it from every other device in the Union market. Second, traceability — when an incident occurs, a recall is issued, or a field safety corrective action is needed, the UDI is how the affected units are located. Third, transparency — the UDI is the identifier through which device information is published to the public via the UDI database inside EUDAMED.

The legal obligation to implement UDI sits with the manufacturer. MDR Article 27(3) requires the manufacturer to assign a UDI to the device and, where applicable, to all higher levels of packaging, before placing the device on the market. The UDI stays with the device for the whole of its time on the market and is updated when the device changes in a way that affects identification.

UDI-DI, UDI-PI, and Basic UDI-DI — what each one actually is

This is the point where founders most often lose the thread, and the point where getting the definitions right pays off for the rest of the technical file.

UDI-DI — the device identifier. The UDI-DI is the static part of the UDI. It is unique to the manufacturer and to the specific version or model of the device, at a defined level of packaging. If the same physical device is sold at unit level and at carton level, each packaging level gets its own UDI-DI. Change the device model — a new variant, a meaningful design change, a new intended purpose — and a new UDI-DI is required. The UDI-DI is the "what" of the UDI: what is this device, in this packaging.

UDI-PI — the production identifier. The UDI-PI is the variable part. It identifies the unit of production. Depending on the device, the UDI-PI is composed of one or more of the following: the lot number, the serial number, the software identification, the manufacturing date, and the expiry date. The UDI-PI is the "which batch" or "which unit" of that device. For a single-use sterile device, the lot number is usually the relevant UDI-PI. For an implant, the serial number is usually the relevant UDI-PI. For software, the software version is the relevant UDI-PI. The applicable PI elements are set by the rules of the chosen issuing entity and by Annex VI Part C of the MDR.

Together, UDI-DI and UDI-PI form the full UDI carried on the device or its packaging. The UDI-DI identifies the model. The UDI-PI identifies the specific instance of that model.

Basic UDI-DI — the primary access key. Sitting above the UDI-DI is the Basic UDI-DI. MDR Article 2(15) defines it as the primary identifier of a device model and the access key for information stored in the UDI database. The Basic UDI-DI groups together devices that share the same intended purpose, risk class, and essential design and manufacturing characteristics. It is not carried on the label. It is an administrative identifier that lives in the documentation and in the database.

The Basic UDI-DI is the identifier that appears in the EU declaration of conformity, in the technical documentation under Annex II, on the Notified Body's certificate, in the clinical evaluation, and in the Summary of Safety and Clinical Performance. When the technical file, the certificate, and the EUDAMED record all speak about "this device family," the identifier they share is the Basic UDI-DI. A single Basic UDI-DI can group multiple UDI-DIs (one per variant, size, or packaging level), and each UDI-DI can be carried by many physical units, each with its own UDI-PI.

The mental model that helps most founders is a tree. The Basic UDI-DI is the trunk — one per device family as defined by intended purpose, class, and essential design. The UDI-DIs are the branches — one per variant or packaging level. The UDI-PIs are the leaves — one per lot, serial number, or production unit.

Who assigns UDIs — the four issuing entities

A manufacturer does not invent its own UDI numbering scheme. MDR Article 27(2) requires UDIs to be assigned according to the rules of an issuing entity designated by the Commission for the purposes of the UDI system. The Commission designates issuing entities through an implementing act, and the current designated entities for the EU are four: GS1, HIBCC, ICCBBA, and IFA.

  • GS1 is the best-known and most widely used, both in the EU and globally. GS1 standards underpin barcodes across retail, logistics, and healthcare. For most medical device manufacturers entering the EU market, GS1 is the default unless a specific reason points elsewhere.
  • HIBCC (Health Industry Business Communications Council) operates a competing standard historically widespread in parts of the medical device industry, particularly in the United States. HIBCC identifiers are accepted under both FDA UDI and EU MDR UDI systems.
  • ICCBBA (International Council for Commonality in Blood Banking Automation) is the issuing entity for products of human origin — blood, cells, tissues — and for medical devices intimately connected with those products. A startup working on a device that falls into this scope will often find ICCBBA is the appropriate entity.
  • IFA (Informationsstelle für Arzneispezialitäten, based in Germany) is the issuing entity historically used for the German pharmaceutical and medical device market. Manufacturers with a strong German market focus sometimes adopt IFA; most pan-European startups default to GS1.

A manufacturer chooses one issuing entity and works under its rules for the allocation of UDI-DIs and the composition of UDI-PIs. The choice is not neutral — each entity has its own membership model, its own fee structure, and its own technical conventions for how identifiers are encoded and how data carriers (barcodes, data matrix codes, RFID) are constructed. The practical recommendation for most startups is: choose GS1 unless you have a specific reason not to, and make the choice early enough that your label design, your ERP setup, and your Notified Body submission all use the same identifiers from day one.

How UDI maps to EUDAMED registration

UDI is not just an identifier on a label. It is the spine of the EUDAMED device registration module.

MDR Article 28 establishes the UDI database within EUDAMED. Article 28(2) specifies that the UDI database contains, for each Basic UDI-DI and UDI-DI, the data elements listed in Annex VI Part B. The data elements include identification of the device, the applicable risk class, the name and address of the manufacturer, the SRN of the manufacturer, the authorised representative where applicable, the Notified Body that issued the certificate (where relevant), the presence of substances of concern, relevant URLs for the instructions for use, clinical investigation data, and other fields that collectively describe the device at a regulatory level.

MDR Article 29 then places the registration obligation squarely on the manufacturer. Article 29(1) requires the manufacturer, before placing a device (other than custom-made) on the market, to assign a Basic UDI-DI to the device and provide it together with the other core data elements referred to in Annex VI Part B to the UDI database. Article 29(2) requires the manufacturer to keep the information up to date. Article 29(4) requires the Basic UDI-DI to be provided to the Notified Body, where the conformity assessment involves a Notified Body, and to appear on the certificate itself.

Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 sets out the detailed functioning rules for EUDAMED, including the UDI database. Any question about how the UDI database actually operates — data submission, correction procedures, access rights, nomenclature — is answered by reading (EU) 2021/2078 alongside Articles 27, 28, and 29. The mandatory use of EUDAMED modules, including the UDI/device registration module, is conditioned under MDR Article 34 on the Commission declaring the module functional. For current status, see the companion post on EUDAMED status in 2026.

What appears on the label versus what lives in the database

A persistent source of confusion for first-time founders is the difference between what the UDI system requires on the physical label and what it requires in the database. They are not the same thing.

On the label and packaging. Annex VI Part C of the MDR specifies the UDI carrier requirements. The UDI — consisting of UDI-DI plus the applicable UDI-PI elements — must be placed on the label of the device and on all higher levels of packaging. For devices intended to be reused, the UDI must additionally be placed on the device itself (direct marking) unless direct marking is not feasible for reasons specified in the Regulation. The UDI carrier is the means by which the UDI is represented on the label — typically a linear barcode or a GS1 DataMatrix, but other AIDC (Automatic Identification and Data Capture) technologies are permitted. Human-readable interpretation of the UDI must accompany the machine-readable carrier unless space constraints apply and are justified.

In the UDI database. The Basic UDI-DI and the UDI-DI are submitted to the UDI database with the full set of data elements from Annex VI Part B. UDI-PIs themselves (lot, serial, expiry) are not submitted as individual entries in the UDI database — they live on the physical unit and in the manufacturer's own traceability system. The database is the registry of the device model; the production identifiers are the runtime information carried on the unit.

The practical consequence is that the database work and the label work are two different workstreams that must be coordinated. The database contains the regulatory identity of the device family. The label carries the identifier that allows a physical unit to be scanned and traced. Both must agree exactly on the UDI-DI, and both must trace back to the same Basic UDI-DI.

Software as a medical device — the special UDI rules

Software presents a genuinely different UDI problem from physical hardware, and Annex VI Part C addresses it directly.

For software that is itself a medical device (SaMD) under MDR Article 2(1), a new UDI-DI is required whenever there is a modification that changes the original performance, the safety, or the intended use of the software, the interpretation of data, or any other aspect related to the software's identification. Minor software revisions that do not affect these elements may share an existing UDI-DI but require a new UDI-PI reflecting the new software version.

The UDI carrier for software does not appear on a physical label in the same way as for hardware. Annex VI Part C specifies that for software delivered physically (for example on a USB stick), the UDI is on the physical packaging. For software delivered electronically, the UDI is provided on a readily accessible screen — for example an "about" screen — and is also present in machine-readable form (for example in the software's programming commands or API output) to support electronic traceability.

The lesson for SaMD startups is to decide early how the UDI will be surfaced in the product. Retrofitting a UDI display into a shipped UI after certification is painful. Deciding at design time that the "about" screen shows the Basic UDI-DI, the UDI-DI, and the software version as UDI-PI — and that the same identifiers are accessible to automated tooling — costs almost nothing and removes a whole category of late-stage findings.

Implementation timeline by risk class

UDI obligations under the MDR did not go live for all devices on the same day. The Regulation staged the direct marking and labelling obligations by risk class, to give manufacturers time to adapt packaging and production lines. The staggered timelines are set out in MDR Article 123 (transitional provisions) and in Article 27 itself for the specific direct marking obligations.

The staged logic is that higher-risk devices were required to carry the UDI on the label earlier, with lower-risk classes following later. Direct marking of reusable devices was staged even further. The effect for a startup today is that, for any device newly placed on the EU market under MDR, full UDI compliance applies from the outset — the transitional windows primarily mattered for devices that had legacy pre-MDR identifiers to migrate. A new device, starting now, plans for full UDI-DI, UDI-PI, Basic UDI-DI, labelling, direct marking where applicable, and EUDAMED registration as part of the initial launch plan.

Because the specific dates in Article 123 were subsequently amended (notably by Regulation (EU) 2023/607) and because the mandatory use of the EUDAMED UDI module is tied to Article 34, a founder should read the latest consolidated text of Articles 27, 29, 34 and 123 and check the current EUDAMED module status before relying on a specific effective date.

Common founder misunderstandings

A handful of misunderstandings show up again and again.

"The UDI is one number." It is not. It is a structured identifier made of a UDI-DI and a UDI-PI, assigned under the rules of an issuing entity, with a Basic UDI-DI sitting above it in the database.

"The Basic UDI-DI is just a shorter UDI." It is not. It is a higher-level grouping identifier that groups multiple UDI-DIs under one device family, and it is the access key used in the database, the technical file, the certificate, and the declaration of conformity.

"We can pick our own numbering scheme." No. UDIs must be assigned under the rules of a Commission-designated issuing entity — GS1, HIBCC, ICCBBA, or IFA.

"UDI is just a label requirement." It is a label requirement, a database requirement, a technical documentation requirement, a certificate requirement, and a traceability requirement. Treating it as a label project causes trouble downstream.

"Our software does not need a UDI because it has no label." SaMD needs a UDI. Annex VI Part C sets out how software UDIs are surfaced on screens and in machine-readable form.

"We will retrofit UDI after certification." UDI touches the label, the packaging, the IFU, the technical documentation, the certificate, and EUDAMED. Retrofitting means reopening all of these. Do it at design time.

The Subtract to Ship angle on UDI

UDI is an unusually good candidate for the Subtract to Ship framework for MDR because the actual work is finite and the waste is predictable.

The real work is: choose one issuing entity (almost always GS1 for a new startup without a specific reason to go elsewhere); define the Basic UDI-DI strategy so that device variants are grouped sensibly and consistently with the technical documentation; allocate UDI-DIs at each relevant packaging level; define which UDI-PI elements apply (lot, serial, software version, manufacturing date, expiry) based on the device type; design the label and, where applicable, the direct marking so the UDI carrier is machine-readable and human-readable; register the Basic UDI-DI and UDI-DI with the Annex VI Part B data elements in the UDI database when the module is mandatory; and maintain the data.

Everything else — the multi-vendor parallel UDI strategies, the speculative RFID projects layered on top of the mandatory carrier, the custom database tooling that replicates EUDAMED fields, the "UDI readiness workshops" that are not grounded in Articles 27 to 29 — is a candidate for removal. If a proposed activity does not trace to Article 27, 28, 29, Annex VI, or (EU) 2021/2078, it does not belong in a startup UDI plan.

Reality Check — Where do you stand on UDI?

  1. Can you state the Basic UDI-DI of each device family you plan to place on the EU market, and does that grouping match your intended purpose and risk class?
  2. Have you chosen an issuing entity (GS1, HIBCC, ICCBBA, or IFA), and do you understand that entity's allocation rules?
  3. For each device, do you know which UDI-PI elements apply — lot, serial, software version, manufacturing date, expiry — and why?
  4. Does your label design include a machine-readable UDI carrier and a human-readable interpretation consistent with Annex VI Part C?
  5. For any reusable device in your portfolio, have you evaluated the direct marking requirement?
  6. For any software device, have you decided how the UDI will appear on screen and in machine-readable form?
  7. Do your technical documentation, your draft declaration of conformity, and your Notified Body submission all use the same Basic UDI-DI?
  8. Have you mapped which Annex VI Part B data elements you will submit to the UDI database, and do you have a process to keep them up to date?

If you cannot answer five or more of these cleanly, UDI is not yet a solved workstream in your plan.

Frequently Asked Questions

What does UDI stand for? UDI stands for Unique Device Identification. It is the system established by MDR Article 27 for uniquely identifying medical devices on the EU market and enabling their traceability.

What is the difference between a UDI-DI and a UDI-PI? The UDI-DI is the fixed part of the UDI and identifies the device model at a specific packaging level. The UDI-PI is the variable part and identifies the specific production unit — lot, serial number, software version, manufacturing date, or expiry date, depending on the device. Together they form the full UDI carried on the label.

What is a Basic UDI-DI? The Basic UDI-DI is defined in MDR Article 2(15) as the primary identifier of a device model and the access key for information stored in the UDI database. It groups devices that share the same intended purpose, risk class, and essential design and manufacturing characteristics. It appears in the technical documentation, on the certificate, and in the EU declaration of conformity, but it is not carried on the label.

Who assigns UDIs under the MDR? The manufacturer assigns UDIs, but only according to the rules of an issuing entity designated by the European Commission. The currently designated entities are GS1, HIBCC, ICCBBA, and IFA. Most startups use GS1.

Does software need a UDI? Yes. Software that is itself a medical device must carry a UDI. Annex VI Part C of the MDR sets out how UDIs are surfaced for software — on "about" screens and in machine-readable form — and specifies when a software change triggers a new UDI-DI versus a new UDI-PI.

Where is the UDI registered? In the UDI database within EUDAMED. MDR Article 28 establishes the database and Article 29 requires the manufacturer to submit the Basic UDI-DI together with the data elements in Annex VI Part B before placing the device on the market. Commission Implementing Regulation (EU) 2021/2078 governs the detailed operation of EUDAMED including the UDI module.

Is UDI mandatory today? UDI as a system is established by MDR Article 27 and applies to devices placed on the EU market under MDR. The mandatory use of the EUDAMED UDI database module is conditioned under Article 34 on the Commission declaring the module functional. Founders should read the latest consolidated text and the current EUDAMED status before relying on a specific effective date.

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), Article 28 (UDI database), Article 29 (registration of devices), Article 33 (European database on medical devices — Eudamed), Article 34 (functioning of Eudamed), Article 123 (transitional provisions relevant to UDI timelines), Annex VI Part B (information to be submitted to the UDI database) and Annex VI Part C (the UDI system). 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.
  3. European Commission implementing decisions designating issuing entities for the UDI system — currently GS1, HIBCC, ICCBBA, and IFA. Readers should consult the Commission's EUDAMED information page for the current list and any updates.

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 interacts with your specific device architecture, read this post alongside the detailed spokes on Articles 27-29, on choosing an issuing entity, and on assigning a Basic UDI-DI.