A Basic UDI-DI is assigned by the manufacturer, not generated by EUDAMED and not generated by EUDAPrep. The manufacturer obtains the identifier from one of the four UDI issuing entities the European Commission designated under MDR Article 27(2), applies the MDCG 2018-1 Rev. 4 §5 grouping rules to its portfolio, and registers one Basic UDI-DI per device model family in EUDAMED. This page walks through that decision: what a Basic UDI-DI is, how it differs from the other three UDI identifiers, what MDCG 2018-1 Rev. 4 actually requires, how to pick the issuing entity, how the GS1 Global Model Number is built, when a new Basic UDI-DI is required, and which assignment errors EUDAMED’s business-rule validation catches before the portal accepts the submission.
What a Basic UDI-DI is (and what it is not)
A Basic UDI-DI is the device-model-level identifier in the UDI hierarchy. It groups devices that share an intended purpose, a risk class, essential design and manufacturing characteristics, and a name into a single regulatory record. MDR Article 27 establishes the UDI system; MDR Annex VI Part C defines the Basic UDI-DI as the primary identifier for a device model and the access key for related information in EUDAMED.
It is not a barcode. It does not appear on the device, on the inner packaging, or on the outer packaging. It does not get scanned at any point in the supply chain. The Automatic Identification and Data Capture (AIDC) carrier on the device label is the UDI-DI plus UDI-PI; the Basic UDI-DI lives entirely inside EUDAMED, the EU Declaration of Conformity, the technical documentation, certificates, and field safety notices.
It is also not the UDI-DI. The UDI-DI is the trade-item-level identifier issued to each commercial configuration: a 5 mL syringe and a 10 mL syringe in the same product family carry the same Basic UDI-DI but different UDI-DIs. MDCG 2018-1 Rev. 4 §3.2 carries the definitional anchor; §4.1 carries the hierarchy.
A Basic UDI-DI groups a model family in EUDAMED. A UDI-DI identifies one trade unit beneath it. The Basic UDI-DI is regulatory; the UDI-DI is operational and appears on the device.
Basic UDI-DI vs UDI-DI vs UDI-PI vs EUDAMED-DI
Four identifiers operate at different levels of the UDI system. Confusing them is the most common cause of submission rejection, so the disambiguation matters.
| Identifier | Level | Required on the physical device? | Issued by | Used in EUDAMED for |
|---|---|---|---|---|
| Basic UDI-DI | Device model family | No | UDI issuing entity (GS1, HIBCC, ICCBBA, IFA) | The parent record in the UDI Devices module; referenced in the Declaration of Conformity and technical documentation |
| UDI-DI | Commercial unit of trade | Yes, as part of the UDI carrier | UDI issuing entity | The child record under the Basic UDI-DI; identifies each configuration, size, or sterile state |
| UDI-PI | Production unit (lot, serial number, expiry) | Yes, as part of the UDI carrier | Manufacturer at production | Pairs with UDI-DI at scan; not registered separately in EUDAMED |
| EUDAMED-DI | Legacy device record | No | EUDAMED itself | The identifier used by legacy devices on extended certificates that do not enter the UDI system; replaces the Basic UDI-DI on that lane |
The first three are MDR Annex VI Part C identifiers. EUDAMED-DI is the legacy-device fallback the Commission introduced under the gradual EUDAMED roll-out so that devices under MDR Article 120 extended certificates can be registered without a UDI issuing entity in the loop. The MDR Annex VI Part C hierarchy applies to every new MDR device; the EUDAMED-DI route is the exception, not the rule.
The full four-identifier comparison sits one level deeper than the scope of this page; the EUDAMED registration pillar covers the hierarchy alongside the actor and module structure.
MDCG 2018-1 Rev. 4: the Basic UDI-DI assignment rulebook
MDCG 2018-1 Rev. 4 is the Medical Device Coordination Group’s guidance on Basic UDI-DI assignment. Section 5 is the load-bearing part. It states that a Basic UDI-DI groups devices sharing four characteristics, and changing any one of them forces a new Basic UDI-DI:
- Same intended purpose. The Annex I §23.4 intended-purpose statement is identical across the grouped devices. A device repositioned for a new clinical use leaves the original Basic UDI-DI behind.
- Same risk class. A Class IIa device and a Class IIb device do not share a Basic UDI-DI even when the design is otherwise identical. Reclassification under a Notified Body opinion or under Annex VIII rule changes triggers a new Basic UDI-DI.
- Same essential design and manufacturing characteristics. This is the elastic criterion. MDCG 2018-1 Rev. 4 §5 treats material change, geometry change at the load-bearing level, source of supply for an active substance, sterilisation method, and software architecture as essential. Cosmetic, label, and packaging changes are not essential.
- Same device name or trade name. A trade-name change tied to a regulatory event (rebrand under a divestment, change of legal manufacturer) forces a new Basic UDI-DI. A marketing rename without a regulatory event does not.
A device family can carry many UDI-DIs under one Basic UDI-DI. The §5 rules constrain when the parent identifier changes; the UDI-DI changes more freely with size, sterile state, or configuration. MedTech Europe’s practical guide reads the same way and is a useful working reference for RA teams applying §5 across a multi-device portfolio.
Issuing-entity decision: GS1, HIBCC, ICCBBA, IFA
MDR Article 27(2) designates the entities authorised to issue UDIs for the EU market. The Commission’s implementing decisions name four: GS1, HIBCC, ICCBBA, and IFA. Each operates a different identifier format and serves a different segment of the medical-device market.
| Entity | Device types covered | Identifier format issued | Membership / fee model | Geographic operator base | Typical fit |
|---|---|---|---|---|---|
| GS1 | General medical devices (Class I to Class III); IVDR Class A to Class D | Global Model Number (GMN) for Basic UDI-DI; Global Trade Item Number (GTIN) for UDI-DI | Annual licence by GS1 member organisation; fees scale by company turnover and SKU count | National GS1 organisations across all EU member states | The majority of general medical-device portfolios. The natural choice when the manufacturer already holds a GS1 company prefix for retail or supply-chain reasons. |
| HIBCC | General medical devices; healthcare items with a Health Industry Bar Code background | HIBCC Basic UDI-DI format using the LIC (Labeler Identification Code) and product number | One-time enrolment plus annual fee; broadly comparable to GS1 in the per-SKU range | US-based; serves EU manufacturers through international membership | Manufacturers already in the HIBC system from a US or Japanese market entry. Common for orthopaedic implants and reusable surgical instruments. |
| ICCBBA | Blood, cells, tissues, organs, and human-cell products | ISBT 128 identifier (the global standard for the transfusion and transplant chain) | Annual membership by facility type | US-based; ISBT 128 used internationally | Manufacturers whose devices intersect the blood, cell, tissue, or organ chain. ISBT 128 is the operative standard for that segment and ICCBBA is the only EC-designated entity that issues it. |
| IFA | Pharmaceuticals and medical devices placed on the German market | PPN-based identifier (Pharmacy Product Number, the IFA standard) | Per-product fee under the IFA Healthcare structure | Germany; serves the DACH region | Devices distributed primarily in the German pharmacy and hospital channel, especially where the device is co-supplied with pharmaceuticals on the same logistics chain. |
The brief is not to pick a winner. The four entities are each designated by the Commission; the choice depends on the manufacturer’s existing identifier holdings, the device type, and the distribution channel. A general medical-device manufacturer with a GS1 prefix already in use for retail packaging defaults to GS1 because the GMN issuance reuses the same prefix; a blood-product manufacturer defaults to ICCBBA because ISBT 128 is the global standard for that lane; a manufacturer with a German pharmacy footprint may choose IFA because the PPN is already in the local distribution database. Where two routes are genuinely open, the operational tie-breaker is which entity the manufacturer’s quality and labelling systems already encode.
Basic UDI-DI structure: how the GS1 GMN is built
GS1 issues the dominant share of EU Basic UDI-DIs because most general medical devices route through it. The format is the Global Model Number. The Basic UDI-DI under GS1 is therefore a GMN, while the UDI-DI under GS1 is a Global Trade Item Number (GTIN). The two are distinct identifier types at distinct levels; the GS1 General Specifications §GMN sets out the rules.
A GMN is constructed in three segments:
- GS1 Company Prefix. A 5-digit to 12-digit prefix issued to the manufacturer by its national GS1 member organisation. The prefix length is fixed for each company and reflects the SKU volume the prefix is sized for.
- Model reference. A manufacturer-assigned alphanumeric string that, together with the company prefix, totals 23 characters before the check.
- Check character pair. Two characters generated by the GS1 GMN check-character algorithm over the preceding 23 characters. The algorithm and the GMN character set are documented in the GS1 General Specifications; the EUDAMED business-rule validation recomputes the pair to confirm it matches.
A worked example illustrates the structure. A Bavarian manufacturer of Class IIa reusable surgical instruments holds GS1 Company Prefix 04054321 (8 digits). The Basic UDI-DI for a reusable laparoscopic grasper model family with internal model reference LAPGRASP01 is constructed as:
GS1 Company Prefix : 04054321
Model reference : LAPGRASP01 (padded with the agreed scheme to fill 23 chars)
Concatenation : 04054321LAPGRASP01XXXXX (23 chars total before check)
Check character : 2-character pair from GS1 algorithm, e.g. 7K
Final GMN : 04054321LAPGRASP01XXXXX7KThe UDI-DI assigned to the 33 cm variant of the same grasper is a separate GTIN under the same company prefix and does not share characters with the GMN. The Basic UDI-DI sits at the family level; the GTIN sits beneath it.
HIBCC, ICCBBA, and IFA each construct the Basic UDI-DI under their own rules: HIBCC pairs the Labeler Identification Code with the product number; ICCBBA issues an ISBT 128 identifier; IFA issues a PPN. Where the page below references “GMN,” substitute the equivalent format for the chosen entity.
When to assign a new Basic UDI-DI vs reuse an existing one
The §5 grouping rules from MDCG 2018-1 Rev. 4 apply at every change event. Three scenarios cover the most common SME cases:
Software-only update on a connected device. A firmware patch that fixes a logging bug without changing the intended purpose, the risk class, the essential design, or the trade name leaves the Basic UDI-DI in place. A new UDI-DI may be required if the software version is part of the UDI-DI scope under MDR Annex VI Part C; the Basic UDI-DI is not.
New size variant of an existing instrument. A 33 cm variant of a 28 cm reusable grasper, sharing intended purpose, risk class, essential design, and trade name, attaches to the existing Basic UDI-DI as a new UDI-DI record. No new Basic UDI-DI is required; the family grows by one trade unit.
Reclassification from Class IIa to Class IIb. A device reclassified upward under Annex VIII rule changes triggers all four MDCG 2018-1 Rev. 4 §5 tests for re-evaluation, and the risk-class test alone fails. A new Basic UDI-DI is required, and the device is registered as a new model family in EUDAMED.
The MDR Annex VI Part C grouping principle is the underlying rule; MDCG 2018-1 Rev. 4 §5 is the operational reading. Where a change event is genuinely borderline, the §5 wording is the document the manufacturer’s PRRC and the Notified Body work from, not a paraphrase of it.
Common Basic UDI-DI assignment errors EUDAMED’s business-rule validation catches
The EUDAMED submission pipeline runs deterministic schema and business-rule validation on every record before the portal accepts the bulk upload. The business rules are published as part of the EC’s UDI devices business-rules document and are applied identically on every submission. Five Basic UDI-DI errors recur:
| Error | What triggers it | Upstream fix |
|---|---|---|
| Basic UDI-DI check-character failure | The GS1 GMN check-character pair does not match the algorithm output over the preceding characters. Usually a transcription error between the issuing-entity record and the EUDAMED submission. | Regenerate the check character from the issuing-entity record; do not retype the identifier. |
| Duplicate Basic UDI-DI under the same manufacturer SRN | Two device-model families have been assigned the same Basic UDI-DI by mistake, or a previously-retired identifier has been reused. | Issue a new identifier through the issuing entity; reassign one of the conflicting records. |
| Incorrect issuing-entity prefix | The issuing-entity prefix encoded in the identifier does not match the issuing entity declared in the EUDAMED submission. | Confirm the issuing entity matches the prefix; re-export the XML with the correct issuing-entity tag. |
| Basic UDI-DI / UDI-DI mismatch on grouping | A UDI-DI is submitted under a Basic UDI-DI it does not belong to, often because a new variant was attached to the wrong family. | Re-apply MDCG 2018-1 Rev. 4 §5 to the variant; attach the UDI-DI to the correct Basic UDI-DI parent. |
| Malformed GMN length | The concatenated GMN exceeds or falls short of the 25-character total (23 plus the two-character check). | Re-pad the model reference under the issuing-entity rule and regenerate the check pair. |
These errors are caught at the schema and business-rule layer, not at the regulatory-judgement layer. They are mechanical, deterministic, and reproducible.
Basic UDI-DI validation before XML export
The Basic UDI-DI validation step is the section of the EUDAMED submission workflow where each Basic UDI-DI assigned via the issuing entity is checked against the EC’s published schema and business rules before XML export. The validation runs on the structure (check character, length, prefix match), on the EUDAMED business rules (uniqueness under SRN, parent-child consistency with UDI-DI records), and on the manufacturer’s own declared metadata (issuing entity declared, device class, intended purpose). Where the Basic UDI-DIs have already been obtained through GS1, HIBCC, ICCBBA, or IFA, the deterministic schema and business-rule check runs against them before XML export; the issuance step itself stays with the issuing entity.
Where the Basic UDI-DI lands in the EUDAMED submission
The Basic UDI-DI is the parent record in the EUDAMED UDI Devices module. The submission carries the manufacturer’s SRN (issued at the actor-registration stage), the Basic UDI-DI, the issuing entity that issued it, and the device-level metadata (risk class, EMDN code, intended purpose, status). UDI-DI records are then attached as children of the Basic UDI-DI; each UDI-DI carries its own metadata block plus the parent reference.
The data path runs SRN → Basic UDI-DI → UDI-DI in the XML structure. The XML methods cluster covers the file layout for bulk upload; this page covers the assignment decision that feeds the parent identifier into that file.
The Basic UDI-DI is also visible in the EUDAMED public search, the portal’s read-only interface for looking up records already submitted. Where the manufacturer or an external party needs to confirm a Basic UDI-DI is registered against the right SRN, the public search at the EC’s EUDAMED Public portal is the lookup route; it surfaces the Basic UDI-DI, the manufacturer, and the UDI-DI children attached to it. The dates for mandatory module use are set by Commission Decision (EU) 2025/2371 and the EUDAMED registration deadlines cluster carries the calendar.