---
title: Basic UDI-DI: The Master Identifier for Your Device Family
description: Basic UDI-DI is the master identifier for a device family under MDR. Here is what it is, how to assign it, and how it differs from UDI-DI.
authors: Tibor Zechmeister, Felix Lenhard
category: EUDAMED, UDI & Registration
primary_keyword: Basic UDI-DI master identifier
canonical_url: https://zechmeister-solutions.com/en/blog/basic-udi-di-master-identifier
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Basic UDI-DI: The Master Identifier for Your Device Family

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **The Basic UDI-DI is the master identifier for a device family under the MDR. Defined in Regulation (EU) 2017/745 Article 2(15), it is the primary identifier of a device model and the main access key for information stored in the UDI database. It groups together devices that share the same intended purpose, risk class, and essential design and manufacturing characteristics. Unlike the UDI-DI, which is model-and-packaging-level specific and printed on the label, the Basic UDI-DI is an administrative identifier that never appears on the physical product. It lives in the technical documentation under Annex II, on the EU declaration of conformity, on the Notified Body certificate, in the Summary of Safety and Clinical Performance, and in the UDI database inside EUDAMED. One Basic UDI-DI can sit above many UDI-DIs — one per variant, size, or packaging level. A startup assigns the Basic UDI-DI under the rules of its chosen issuing entity (GS1, HIBCC, ICCBBA, or IFA) before applying for conformity assessment, and it is the identifier the Notified Body writes on the certificate.**

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

---

## TL;DR

- The Basic UDI-DI is 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.
- It groups devices that share the same intended purpose, risk class, and essential design and manufacturing characteristics into a single device family.
- It is not carried on the label. It lives in the technical documentation, on the EU declaration of conformity, on the Notified Body certificate, and in the UDI database inside EUDAMED.
- One Basic UDI-DI sits above many UDI-DIs (one per variant or packaging level), which in turn sit above many UDI-PIs (one per lot, serial number, or software release).
- Basic UDI-DIs are assigned under the rules of the issuing entity chosen under MDR Article 27(2) — GS1, HIBCC, ICCBBA, or IFA — and Commission Implementing Regulation (EU) 2021/2078 governs the detailed functioning of the UDI database inside EUDAMED.

---

## The identifier the label never shows

A founder writing a first technical file reaches a strange moment. The document template asks for a Basic UDI-DI. The label template asks for a UDI. The Notified Body application asks for a Basic UDI-DI. The barcode printout carries something that looks nothing like the Basic UDI-DI in the technical file. The two identifiers live in different places and follow different rules, and the regulation assumes the reader already knows why.

The short answer is that the Basic UDI-DI and the UDI-DI answer two different questions. The UDI-DI answers "what specific thing, at what packaging level, is this individual unit." The Basic UDI-DI answers "what device family does this belong to, for the purposes of the regulatory dossier and the database." They are both needed. Neither replaces the other. And the identifier that matters most for the technical file, the certificate, and the declaration of conformity is the one that never gets printed on the product.

This post is the definitive orientation to the Basic UDI-DI. It covers the definition, the reason the structure exists, how to assign one, what counts as a device family, the relationship to the UDI-DI, where the Basic UDI-DI appears in EUDAMED, and the mistakes founders reliably make. For the broader orientation to UDI, read [What is UDI?](/blog/what-is-udi). For the article-by-article reading, see [MDR Articles 27-29 UDI requirements decoded](/blog/mdr-articles-27-29-udi-requirements). For the contrast with the production identifier, see [UDI-DI versus UDI-PI](/blog/udi-di-vs-udi-pi).

## Definition — what Article 2(15) actually says

MDR Article 2(15) defines the Basic UDI-DI as the primary identifier of a device model. Paraphrased closely from the Regulation: it is the identifier assigned at the level of the device unit of use, which is the main access key for information in the UDI database, and it is referenced in relevant certificates and EU declarations of conformity. The MDR text also uses the related term "UDI-DI" in Article 2(15a), defining the UDI-DI as the unique numeric or alphanumeric code specific to a model of device and used as the access key to information stored in the UDI database. Annex VI Part C is the annex that contains the technical rules for the whole UDI system, including both identifier types and the change categories that trigger new codes.

Three elements in the Article 2(15) definition carry the practical weight.

**"Primary identifier of a device model."** The Basic UDI-DI is not the identifier of a single SKU or a single packaging level. It is the identifier of the model-family — the level at which the regulator and the Notified Body think about the device for certification, clinical evaluation, and post-market surveillance purposes.

**"Main access key for information stored in the UDI database."** Everything the UDI database knows about a device family is retrievable by the Basic UDI-DI. The Annex VI Part B data elements — risk class, manufacturer SRN, Notified Body, IFU URLs, substances of concern, clinical investigation information — are hung off the Basic UDI-DI as the anchor.

**"Referenced in certificates and declarations of conformity."** The Basic UDI-DI is the identifier the Notified Body writes on the certificate under MDR Article 29(2). It is the identifier the manufacturer writes on the EU declaration of conformity. It is the identifier that ties the regulatory paperwork together.

## Why the structure exists at all

A reasonable question is why the Regulation needs a separate identifier above the UDI-DI. The UDI-DI is already model-specific. Why add another layer?

The answer comes from how device families actually look. A single "model" from the manufacturer's perspective is rarely a single SKU. It is a family — the same device in a small, medium, and large variant, sold at unit level and at carton level, with a left-hand and right-hand version, with a sterile and a non-sterile configuration. Each of those permutations gets its own UDI-DI because the label has to carry an identifier that exactly matches the physical object on the shelf. But the regulator's questions — what is the intended purpose, what is the risk class, what is the clinical evidence, what is the Notified Body certificate — are not questions about the specific SKU. They are questions about the family.

Without a Basic UDI-DI, the Notified Body certificate would either have to list every UDI-DI in the family (unwieldy, and needing an amendment every time a new variant ships) or reference the "device" with ambiguous text. With a Basic UDI-DI, the certificate names one identifier that stably covers the whole family for as long as the family's essential characteristics do not change.

## How to assign a Basic UDI-DI

A manufacturer does not invent its own Basic UDI-DI. It assigns one under the rules of the issuing entity it chose under MDR Article 27(2) — GS1, HIBCC, ICCBBA, or IFA. Each entity has its own syntax for Basic UDI-DIs. GS1, the most common choice for EU startups, uses a GMN (Global Model Number) as the Basic UDI-DI. HIBCC uses its own structure. ICCBBA and IFA do likewise under their respective rule sets.

The operational steps on a first project look like this.

1. **Choose the issuing entity.** For most startups without a specific reason to go elsewhere, GS1 is the default. See [Choosing a UDI issuing entity](/blog/choosing-udi-issuing-entity) for the decision framework.
2. **Register with the entity and obtain the manufacturer prefix.** GS1 issues a company prefix. HIBCC issues a Labeler Identification Code. The prefix is the root from which Basic UDI-DIs and UDI-DIs are generated.
3. **Define the device families.** This is the substantive step. A device family is a set of devices that share the same intended purpose, risk class, and essential design and manufacturing characteristics. The family definition is a regulatory judgment, not an administrative convenience. See the next section.
4. **Allocate one Basic UDI-DI per family under the entity's syntax.** For GS1, this means generating a GMN for each family. The result is a short alphanumeric code that goes into the technical file and the UDI database.
5. **Record the Basic UDI-DI in the technical documentation under Annex II, on the declaration of conformity, and in the Annex VI Part B submission.** The same identifier, in every place it has to appear, before placing any device in the family on the market.
6. **Provide the Basic UDI-DI to the Notified Body** (for Class IIa and above) before applying for conformity assessment, as required by MDR Article 29(2). The Notified Body verifies it and writes it on the certificate.

Basic UDI-DI assignment is a one-time act per family at launch. It is cheap to do well at the start and expensive to fix later.

## What counts as a device family

The family definition is the hardest substantive decision in the whole Basic UDI-DI workflow. Get it too narrow and every variant needs its own dossier. Get it too broad and the Notified Body rejects the grouping because the devices are not actually the same family in the regulatory sense.

The three binding criteria from Article 2(15) are intended purpose, risk class, and essential design and manufacturing characteristics. A useful working reading of each:

**Same intended purpose.** Every device under one Basic UDI-DI must share the same intended purpose as defined in Article 2(12). Different intended purposes mean different families. A catheter intended for cardiovascular access and a catheter intended for urological use are different intended purposes and must not share a Basic UDI-DI, even if the physical devices look similar.

**Same risk class.** Every device under one Basic UDI-DI must share the same class under MDR Article 51 and Annex VIII. A Class IIa variant and a Class IIb variant of "the same" device belong to different Basic UDI-DIs. The classification is family-defining.

**Same essential design and manufacturing characteristics.** This is the judgment-heavy criterion. Variants in size, length, or non-essential accessories can usually stay inside one family. Variants in the principle of operation, the active substance, the core material in contact with the body, or the software architecture typically cannot. The test is whether the differences affect the safety and performance profile in a way that would require separate clinical evaluation or separate Annex I GSPR analysis.

The practical workflow we recommend is: draft a proposed family grouping, list the variants you intend to include, walk the list past the three criteria, and if any variant fails any criterion, split it into its own family with its own Basic UDI-DI. Do this before the technical file is written, because the technical file is structured around the Basic UDI-DI and restructuring afterwards is painful.

The full operational walkthrough with worked examples is in [How to assign a Basic UDI-DI](/blog/how-to-assign-basic-udi-di).

## The relationship to UDI-DI

The tree metaphor is the clearest way to hold the relationship in mind.

- **Basic UDI-DI** is the trunk. One per device family as defined above.
- **UDI-DIs** are the branches. One per variant (size, configuration, left/right, sterile/non-sterile) and one per packaging level (unit, inner pack, carton, pallet).
- **UDI-PIs** are the leaves. One per production unit — lot, serial number, software version, manufacturing date, expiry date, depending on the device.

Two consequences of the tree structure matter for daily work.

First, the Basic UDI-DI and the UDI-DI are never the same code, and one does not substitute for the other. A Notified Body certificate that carries a UDI-DI instead of a Basic UDI-DI is wrong. A label that carries a Basic UDI-DI instead of a UDI-DI is wrong. Each identifier has exactly one place it belongs.

Second, the Basic UDI-DI only changes when the family itself changes — when a variant is added that falls outside the existing intended purpose, risk class, or essential design criteria, at which point it belongs in a new family with a new Basic UDI-DI. Adding a new size to an existing family produces a new UDI-DI (for the new SKU) under the existing Basic UDI-DI, not a new Basic UDI-DI. The UDI-DI change rules in Annex VI Part C — model change, version change, labelling change affecting identification, intended purpose change — are the trigger list for new UDI-DIs. A change that crosses the family boundary is simultaneously a new UDI-DI and a new Basic UDI-DI.

For worked hardware-and-software examples, see [UDI-DI versus UDI-PI in practice](/blog/udi-di-vs-udi-pi).

## Where the Basic UDI-DI appears in EUDAMED

EUDAMED, established under MDR Article 33 and operationalised by Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021, holds the UDI database module where Basic UDI-DIs are registered.

When a manufacturer registers a device under MDR Article 29(1), the Basic UDI-DI is the anchor of the registration. The Annex VI Part B data elements — device identification, packaging configurations, applicable risk class, manufacturer name and address, Single Registration Number, authorised representative where applicable, Notified Body identification number, URLs for the instructions for use, presence of substances of concern, clinical investigation information — are all hung off the Basic UDI-DI. The UDI-DIs for each variant and packaging level are then linked under the Basic UDI-DI.

The retrieval pattern mirrors the storage pattern. A competent authority, a healthcare provider, or a member of the public looking up a device in EUDAMED uses the Basic UDI-DI as the access key. From there the full Annex VI Part B dataset for the family is visible, and the linked UDI-DIs show how the family decomposes into SKUs.

Commission Implementing Regulation (EU) 2021/2078 is the reference text for how the UDI database actually operates — data submission, correction, access rights, nomenclature (EMDN), and the technical handling of the Basic UDI-DI and UDI-DI records. Any detailed question about EUDAMED behaviour is answered by reading (EU) 2021/2078 alongside Articles 27, 28, and 29. For the current functional status of the UDI module, see [EUDAMED status in 2026](/blog/eudamed-status-2026).

## Common mistakes on Basic UDI-DI

Six misreadings appear again and again on first projects.

**Using the Basic UDI-DI on the label.** The Basic UDI-DI does not belong on the label. The label carries the UDI — UDI-DI plus applicable UDI-PI elements — under Annex VI Part C. The Basic UDI-DI lives in documentation and databases, not on the packaging.

**Assigning one Basic UDI-DI to everything the company makes.** A company that produces a catheter, an implant, and a software product cannot group them under one Basic UDI-DI, even if the company is small and the portfolio is young. Different intended purposes and different risk classes mean different families.

**Assigning one Basic UDI-DI per SKU.** The opposite error. A Basic UDI-DI per size and per packaging level defeats the point of the grouping identifier and produces a regulatory dossier that explodes into parallel paperwork. Variants that share intended purpose, risk class, and essential characteristics belong in one family.

**Treating the Basic UDI-DI decision as cosmetic.** The family grouping determines how the technical file is structured, how clinical evaluation is scoped, how the Notified Body assessment is run, and how the certificate is issued. Changing a Basic UDI-DI grouping after certification is a change that has to be notified to the Notified Body and may require a certificate amendment.

**Forgetting to put the Basic UDI-DI on the declaration of conformity.** MDR Annex IV lists the minimum content of the EU declaration of conformity, and the Basic UDI-DI is among the required elements. A declaration of conformity without it is incomplete.

**Assuming the Basic UDI-DI changes every year or every revision.** It does not. It changes only when the family itself changes — when a variant falls outside the intended purpose, risk class, or essential characteristics of the existing family. Most devices keep the same Basic UDI-DI for years.

## The Subtract to Ship angle on the Basic UDI-DI

The Basic UDI-DI is a small but high-leverage decision, which makes it an excellent application of the [Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr).

The real work is: define the device families under the three Article 2(15) criteria; allocate one Basic UDI-DI per family under the chosen issuing entity's rules; put the Basic UDI-DI in the technical file, the declaration of conformity, the Notified Body submission, and the Annex VI Part B database record; and keep the family definition stable as long as the essential characteristics are stable.

Everything outside that list is a candidate for removal. Parallel Basic UDI-DI schemes maintained alongside the issuing entity's identifiers, custom grouping taxonomies that duplicate the family definition, "Basic UDI-DI governance workshops" untethered from Article 2(15), and speculative per-SKU Basic UDI-DIs generated before the family structure is stable — all waste. If a proposed activity does not trace to Article 2(15), Article 27, Annex VI Part C, or (EU) 2021/2078, it comes out.

## Reality Check — Is your Basic UDI-DI strategy solid?

1. For every device you plan to place on the EU market, have you defined the device family under the three Article 2(15) criteria — same intended purpose, same risk class, same essential design and manufacturing characteristics?
2. Can you state the Basic UDI-DI for each family, assigned under the rules of your chosen issuing entity?
3. Does the Basic UDI-DI appear in your technical documentation, on your draft declaration of conformity, and in your planned Annex VI Part B submission?
4. For Class IIa and above, have you planned to provide the Basic UDI-DI to the Notified Body before applying for conformity assessment, as required by Article 29(2)?
5. Do you know the difference between a change that triggers a new UDI-DI (Annex VI Part C categories) and a change that triggers a new Basic UDI-DI (family boundary crossing)?
6. Have you confirmed that the Basic UDI-DI does not appear on any label or packaging in your artwork?
7. Is every UDI-DI in your plan linked to exactly one Basic UDI-DI, and does the grouping hold up under the three family criteria?

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

## Frequently Asked Questions

**What is a Basic UDI-DI in simple terms?**
The Basic UDI-DI is the master identifier for a device family under MDR Article 2(15). It groups together devices that share the same intended purpose, risk class, and essential design and manufacturing characteristics, and it is the main access key for information stored in the UDI database inside EUDAMED.

**Is the Basic UDI-DI printed on the label?**
No. The Basic UDI-DI is an administrative identifier that lives in the technical documentation, on the EU declaration of conformity, on the Notified Body certificate, and in the UDI database. What appears on the label is the UDI — UDI-DI plus applicable UDI-PI elements — in a machine-readable carrier under Annex VI Part C.

**Who assigns the Basic UDI-DI?**
The manufacturer assigns it, but only under the rules of an issuing entity designated by the European Commission — GS1, HIBCC, ICCBBA, or IFA. GS1 uses the Global Model Number (GMN) as the Basic UDI-DI. Each entity has its own syntax and allocation rules.

**How is a Basic UDI-DI different from a UDI-DI?**
The UDI-DI identifies a specific device model at a specific packaging level and is carried on the label. The Basic UDI-DI sits above the UDI-DI and identifies the device family. One Basic UDI-DI typically groups multiple UDI-DIs — one per variant or packaging level — and appears only in documentation and in the database.

**When does a Basic UDI-DI change?**
A Basic UDI-DI changes only when the family itself changes — when a new variant falls outside the existing intended purpose, risk class, or essential design and manufacturing characteristics. Adding a new size or a new packaging level to an existing family produces a new UDI-DI, not a new Basic UDI-DI.

**Does the Basic UDI-DI appear on the Notified Body certificate?**
Yes. MDR Article 29(2) requires the manufacturer to provide the Basic UDI-DI to the Notified Body before applying for conformity assessment, and the Basic UDI-DI appears on the certificate issued by the Notified Body.

**Where in the MDR is the Basic UDI-DI defined?**
In Article 2(15), which defines it as the primary identifier of a device model and the main access key for information stored in the UDI database. The related term UDI-DI is addressed in Article 2(15a) and the full technical rules live in Annex VI Part C.

## Related reading

- [How to register your startup as a manufacturer in EUDAMED](/blog/register-startup-manufacturer-eudamed) — the Article 31 step that precedes any Basic UDI-DI submission.
- [Device registration in EUDAMED](/blog/device-registration-eudamed) — the Article 29 workflow where the Basic UDI-DI is the anchor.
- [What is UDI? The Unique Device Identification system under MDR](/blog/what-is-udi) — the conceptual orientation to UDI as a whole.
- [MDR Articles 27-29 UDI requirements decoded for startups](/blog/mdr-articles-27-29-udi-requirements) — the article-by-article reading of the UDI obligations.
- [UDI-DI versus UDI-PI in practice](/blog/udi-di-vs-udi-pi) — the contrast between the static device identifier and the production identifier.
- [How to assign a Basic UDI-DI](/blog/how-to-assign-basic-udi-di) — the operational walkthrough with worked examples of device family grouping.
- [Choosing a UDI issuing entity: GS1, HIBCC, ICCBBA, IFA](/blog/choosing-udi-issuing-entity) — the decision framework behind Article 27(2).
- [The EU declaration of conformity under MDR](/blog/eu-declaration-of-conformity-mdr) — where the Basic UDI-DI appears in the DoC.
- [The Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr) — the methodology for cutting Basic UDI-DI work to what Article 2(15) actually requires.

## 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 2(15a) (definition of UDI-DI), Article 27 (Unique Device Identification system), Article 29 (registration of devices), and Annex VI Part C (the UDI system, including the technical rules for identifier assignment and the 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?](/blog/what-is-eudamed-european-database-medical-devices). For questions about how the Basic UDI-DI applies to your specific device portfolio — particularly when to split a family and when to keep it unified — read this post alongside [How to assign a Basic UDI-DI](/blog/how-to-assign-basic-udi-di) and [MDR Articles 27-29 UDI requirements decoded](/blog/mdr-articles-27-29-udi-requirements).*

---

*This post is part of the [EUDAMED, UDI & Registration](https://zechmeister-solutions.com/en/blog/category/eudamed-udi) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*