Managing UDI across the EU and the US is not about running two parallel numbering systems. It is about choosing an issuing entity recognised by both jurisdictions — in practice GS1, HIBCC, or ICCBBA — assigning one UDI-DI per device model at each packaging level under that entity's rules, and then submitting the jurisdiction-specific data sets to the two databases that consume them: the EUDAMED UDI database under MDR Articles 27 to 29, and the FDA Global Unique Device Identification Database (GUDID) under the US UDI rule. The physical label carries one UDI carrier. The backend carries two registrations. Get the issuing entity decision and the Basic UDI-DI grouping right at the start and the multi-market cost collapses from "two programmes" to "one programme with two submissions".

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

TL;DR

  • The EU UDI system is established by MDR Articles 27 to 29 and is administered through the UDI database inside EUDAMED. The US UDI system is administered through the FDA's GUDID. This post discusses the FDA system only as a comparison point — the MDR remains the single source of truth for the EU obligations.
  • The EU Commission has designated four UDI issuing entities: GS1, HIBCC, ICCBBA, and IFA. Of these, GS1, HIBCC, and ICCBBA are also accredited by the FDA as US UDI issuing agencies. IFA is not.
  • A manufacturer that picks GS1, HIBCC, or ICCBBA can operate on one identifier scheme for both EU and US markets. A manufacturer that picks IFA will need a separate US issuing agency.
  • The UDI-DI (device identifier) and UDI-PI (production identifier) structure is conceptually shared between the two systems, but the data submitted to EUDAMED (MDR Annex VI Part B) and to GUDID differ in detail. The label carrier can be one; the database submissions are two.
  • The Basic UDI-DI required by MDR Article 2(15) and Annex VI Part B has no US equivalent. US teams sometimes confuse GUDID's Primary DI with the EU Basic UDI-DI — they are not the same concept.

Why multi-market UDI management trips up good teams

The pattern shows up in almost every EU-plus-US launch the team runs. A startup picks GS1 for Europe because that is what the Notified Body expects, builds a label with a GS1 DataMatrix, submits to the UDI database inside EUDAMED, then turns to the US and discovers that GUDID wants a different set of fields, that the Primary DI concept in GUDID does not map cleanly to the Basic UDI-DI the EU technical file uses, and that the labelling reference the regulatory team wrote for one market does not cover both. A week of clean-up turns into a month. Nothing was wrong with the original decisions — they were just made for one market at a time instead of both.

The fix is not technical. It is sequencing. Decide the issuing entity once, decide the Basic UDI-DI grouping once, design the label once, and write the submission dataset twice — once for the EU UDI database under MDR Articles 27 to 29, once for GUDID under the FDA rule. This post is the orientation to how that sequencing actually works, and the trade-offs at each step.

The pillar for this cluster is What is UDI? The Unique Device Identification System Under MDR. Read it first if "UDI-DI" and "Basic UDI-DI" are still fuzzy.

Surface: what actually differs between EU and US UDI systems

Issuing entities recognised by both jurisdictions

The EU and the US both delegate UDI number allocation to third-party issuing bodies rather than running the numbering themselves. The bodies are not identical.

  • GS1. Designated by the European Commission as an issuing entity for the EU UDI system under MDR Article 27. Also accredited by the FDA as a US UDI issuing agency. This is the default choice for any startup intending to address both markets, and for most startups addressing only the EU. GS1 standards are globally interoperable and the data carrier (GS1 DataMatrix or linear) is universally readable.
  • HIBCC (Health Industry Business Communications Council). Designated by the EU Commission. Also accredited by the FDA. Historically strong in US-origin device companies. Works well for a team whose existing ERP and labelling infrastructure was built around HIBCC identifiers.
  • ICCBBA (International Council for Commonality in Blood Banking Automation). Designated by the EU Commission. Also accredited by the FDA. Scope is narrow: products of human origin (blood, cells, tissues) and devices intimately connected with them. If the device is in scope, ICCBBA is usually the right call and is recognised by both jurisdictions.
  • IFA (Informationsstelle für Arzneispezialitäten). Designated by the EU Commission, historically used for the German market. Not an accredited US UDI issuing agency. A startup that picks IFA has committed to a second, separate allocation for the US market.

The practical filter: if the plan is EU plus US (or EU plus almost anywhere with a UDI-like system), choose GS1, HIBCC, or ICCBBA. Only pick IFA if there is a very specific German-market reason and the team accepts the cost of a parallel US scheme.

Single label versus dual label

The label question decomposes into two sub-questions.

Can one UDI carrier on the label satisfy both markets? In practice, yes, when the issuing entity is shared. A GS1 DataMatrix encoded with a GS1 Global Trade Item Number (GTIN) as the DI, plus the applicable PI elements, is readable and valid as a UDI in both the EU and the US. The AIDC representation is the same. The human-readable interpretation is the same.

Does one label layout satisfy the full labelling obligations of both markets? That is a different question, and the answer is "not automatically". MDR Annex I Chapter III and Annex VI Part C set the EU requirements for label content, symbols, and the UDI carrier. The US FDA has its own label content rules. A label that carries one UDI carrier can still fail EU requirements for unique EU-specific symbols, or US requirements for specific wording. The UDI carrier is shared. The surrounding label content is not. Plan for one carrier, one layout, EU-specific and US-specific content blocks resolved via label variants or regional overlays.

UDI-DI versus UDI-PI across the two systems

The DI/PI conceptual split is the same on both sides of the Atlantic. The DI identifies the model at a packaging level. The PI identifies the production unit — lot, serial, software version, manufacturing date, expiry date as applicable. MDR Annex VI Part C sets out the EU rules for which PI elements are required. The FDA rule sets out the US rules. For most device types the applicable PI elements line up, with edge cases at the margins (for example, software version handling and direct-mark triggers can diverge in detail).

Where the two systems diverge meaningfully is above the DI. The MDR introduces the Basic UDI-DI — defined in Article 2(15) as the primary identifier of a device model and the access key for information stored in the UDI database. The Basic UDI-DI groups UDI-DIs that share the same intended purpose, risk class, and essential design and manufacturing characteristics. It is the identifier that appears in the EU declaration of conformity, in the technical documentation under Annex II, and on the Notified Body's certificate. There is no one-to-one equivalent in the US system. The FDA's GUDID has a Primary DI concept, but it operates at packaging level, not at "device family" level. Teams that assume GUDID Primary DI equals EU Basic UDI-DI get the technical file wrong.

Test: a worked multi-market scenario

Take a Class IIa reusable diagnostic device with two physical variants (standard and extended), each sold at three packaging levels (unit box, inner carton of 10, outer carton of 50). The device is a product of the startup; EU MDR certification via a Notified Body is planned; a US 510(k) submission is planned in parallel.

Step 1 — Issuing entity. The team picks GS1. Rationale: recognised by both EU Commission and FDA, best global interoperability, cheapest path to a single label carrier. IFA is out because the US requires a separate scheme. HIBCC is possible but offers no advantage here. ICCBBA is out of scope (not a product of human origin).

Step 2 — Basic UDI-DI grouping. Under MDR Article 2(15), the Basic UDI-DI groups devices sharing intended purpose, risk class, and essential design and manufacturing characteristics. The two variants share intended purpose, risk class (IIa), and essential design — they differ only in a non-essential dimensional parameter. The team assigns one Basic UDI-DI to cover both variants. This Basic UDI-DI will appear on the declaration of conformity, in the technical documentation, on the Notified Body certificate, and as the access key in the EUDAMED UDI database.

Step 3 — UDI-DI allocation. Each variant gets its own UDI-DI at each packaging level. Two variants times three packaging levels equals six UDI-DIs. Each UDI-DI is a distinct GS1 GTIN. This is the same in both jurisdictions — GUDID also expects a distinct DI per packaging level.

Step 4 — UDI-PI composition. The device is reusable and not sterile. The applicable PI is the serial number (for traceability of individual reusable units). Software embedded in the device is covered by a software version as an additional PI element. Lot is not applicable at the unit level. Expiry date is not applicable. The PI composition is the same for both EU and US markets.

Step 5 — Label carrier. The team designs one GS1 DataMatrix per packaging level encoding the GTIN as DI plus the applicable PI elements. One carrier. Both markets. Human-readable interpretation underneath.

Step 6 — Database submissions. Two separate submissions. The EU submission goes to the UDI database inside EUDAMED, carrying the Basic UDI-DI, the six UDI-DIs, and the full set of Annex VI Part B data elements (identification, risk class, manufacturer SRN, authorised representative if applicable, Notified Body, substances of concern, IFU URL, and so on) for each. The US submission goes to GUDID, carrying the six Primary DIs (one per packaging level per variant) with the GUDID data attributes. The two databases do not talk to each other. The team maintains both.

Step 7 — Direct marking. For reusable devices, MDR Annex VI Part C requires direct marking on the device itself unless infeasible. The team plans a laser-etched GS1 DataMatrix on each unit. The same direct mark satisfies the US direct marking requirement for reusable devices.

The net: one issuing entity decision, one Basic UDI-DI, six UDI-DIs, one PI strategy, one label carrier, one direct mark, two database submissions. The work doubles at the submission step only.

Ship: the one-label-many-markets playbook

A compressed operating sequence for a startup that has made the go-multi-market decision.

  1. Fix the issuing entity early. Pick GS1 unless there is an explicit reason (HIBCC because the legacy ERP is HIBCC; ICCBBA because the device is in scope). Do this before the label vendor is briefed and before any labelling prototypes are committed.
  2. Define the Basic UDI-DI strategy against MDR Article 2(15) criteria. Intended purpose, risk class, essential design and manufacturing characteristics. Write the grouping logic down. This is an EU artefact and drives the EU technical file, not a GUDID input.
  3. Allocate UDI-DIs at every packaging level. One per variant per packaging level. The same identifiers are used in both EU and US submissions, but the number of packaging levels is driven by how the device is actually sold, not by jurisdiction.
  4. Decide the PI composition once. Lot, serial, software version, manufacturing date, expiry date. Document which apply and why, keyed to MDR Annex VI Part C. Review against the US rule for any divergence — in most cases there is none.
  5. Design one AIDC carrier. GS1 DataMatrix is the default. One label carrier per packaging level, carrying DI plus applicable PI elements, plus human-readable interpretation.
  6. Resolve label content variants regionally. The UDI carrier is shared. Everything around it — symbols, mandatory statements, IFU references — is resolved through regional label overlays, not through separate UDI schemes.
  7. Write the two database submissions in parallel. Build the EUDAMED Annex VI Part B dataset and the GUDID dataset from the same master record. Track them as two outputs of one internal source of truth. Never let the two diverge.
  8. Lock change control. Any change to the device, the packaging, the software version, or the intended purpose triggers a review of both the EU UDI-DI/Basic UDI-DI and the US Primary DI. Run the review against both jurisdictions every time. One change-control process, two submission outputs.
  9. Do not retrofit. Every decision above is cheap at design time and expensive after certification. The EU-only teams that later add the US and the US-only teams that later add the EU consistently pay more than the teams that sequenced the multi-market decision at the start.

Reality Check — Where do you stand on multi-market UDI?

  1. Have you picked a single issuing entity, and is it one that is recognised by every jurisdiction in your launch plan?
  2. Can you state your Basic UDI-DI grouping logic against the three MDR Article 2(15) criteria (intended purpose, risk class, essential design and manufacturing characteristics) in one paragraph?
  3. Do your EU declaration of conformity, your technical documentation, and your Notified Body submission all reference the same Basic UDI-DI?
  4. Does your US submission plan treat GUDID Primary DI as the packaging-level DI, and does your team know it is not the same concept as Basic UDI-DI?
  5. Is there one label carrier design per packaging level that is valid in every target market, with region-specific label content resolved through overlays rather than through separate UDI schemes?
  6. Is your UDI-PI composition decision documented against MDR Annex VI Part C and cross-checked against the FDA rule?
  7. Does your change-control process trigger a review of every database submission when the device, software, or packaging changes?
  8. If you chose IFA for the EU, have you explicitly planned and budgeted the separate US issuing agency work?

If you cannot answer five or more cleanly, the multi-market UDI programme is not yet sequenced.

Frequently Asked Questions

Can I use the same UDI on my EU and US labels? Yes, if the issuing entity is recognised by both jurisdictions. GS1, HIBCC, and ICCBBA are designated by the European Commission for the EU UDI system under MDR Article 27 and are also accredited as US UDI issuing agencies. A manufacturer using any of these three can carry one UDI on a shared label carrier for both markets.

Is the Basic UDI-DI the same as the GUDID Primary DI? No. The Basic UDI-DI is defined in MDR Article 2(15) as the primary identifier of a device model and groups devices sharing the same intended purpose, risk class, and essential design and manufacturing characteristics. The FDA GUDID Primary DI is a packaging-level identifier. The EU Basic UDI-DI lives in the technical file, the declaration of conformity, and the certificate; the GUDID Primary DI does not. Treating them as equivalent will misalign the EU technical documentation.

Do I have to register the same device in both EUDAMED and GUDID separately? Yes. EUDAMED and GUDID are independent databases. The EU registration is governed by MDR Articles 28 and 29 with the data elements in Annex VI Part B. The US registration is governed by the FDA UDI rule. There is no cross-submission. One change-control process should drive both outputs to keep the two records consistent.

Which issuing entity should a startup choose? For most startups targeting the EU or EU plus other markets, GS1 is the default. It is designated by the European Commission, accredited by the FDA, and has the broadest global interoperability. HIBCC is a reasonable alternative when existing systems are built around it. ICCBBA applies to products of human origin. IFA is only appropriate if the launch is strictly EU-focused (in practice German-market focused) and the team has accepted the cost of a separate US scheme.

Does the EU require UDI for software the same way as for hardware? Yes. MDR Annex VI Part C sets specific rules for software UDIs, including when the UDI appears on an "about" screen and in machine-readable form, and when a software change triggers a new UDI-DI versus a new UDI-PI. The FDA rule has its own software-UDI provisions. Align the software-version handling to both sets of rules at design time.

What happens if I picked IFA and now want to enter the US market? IFA identifiers are not accredited by the FDA. The team will need to allocate a parallel set of identifiers under an FDA-accredited agency (GS1, HIBCC, or ICCBBA). That means a second labelling project, a second GUDID submission dataset, and ongoing dual maintenance. It is recoverable, but it is avoidable by sequencing the issuing entity decision at the start.

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), 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 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 EU UDI system — GS1, HIBCC, ICCBBA, and IFA. Consult the Commission's EUDAMED information page for the current list.
  4. US FDA Unique Device Identification System Final Rule (referenced in this post as the US comparison point only; the MDR remains the single source of truth for all EU obligations discussed). Consult the FDA UDI guidance pages for the current US requirements and the current list of FDA-accredited issuing agencies.

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 for this cluster is What is UDI?. For questions about how multi-market UDI interacts with your specific device architecture and your launch sequencing, read this post alongside the spokes on Basic UDI-DI assignment and on choosing an issuing entity.