The five UDI mistakes that show up in almost every first-time MedTech startup audit are: (1) choosing the wrong issuing entity for the device family under MDR Article 27(2), (2) confusing the Basic UDI-DI with the UDI-DI under Article 2(15) and Article 29(1), (3) missing or unreadable AIDC carrier on the label under Annex VI Part C, (4) an incomplete EUDAMED UDI database entry under Articles 28 and 29(1), and (5) failing to assign a new UDI-DI when a software change meets the trigger criteria in Annex VI Part C. Each mistake traces to a specific article. Each one is fixable before the Notified Body audit if it is caught early.

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

TL;DR

  • Wrong issuing entity for the device family is the first mistake. The choice between GS1, HIBCC, ICCBBA, and IFA under Article 27(2) has permanent consequences and must match the device type and commercial geography.
  • Confusing the Basic UDI-DI (Article 2(15), the grouping identifier that appears on the certificate and in the technical file) with the UDI-DI (the carrier-level identifier) breaks the link between the technical documentation and the EUDAMED entry.
  • Missing or unreadable AIDC carrier on the label is an Annex VI Part C violation. The machine-readable and human-readable interpretation must both be present.
  • An incomplete EUDAMED UDI database entry means the Annex VI Part B data elements were not fully submitted before placing on the market, which Article 29(1) requires.
  • Software UDI-DI not updated on a significant change violates Annex VI Part C. A change that affects identification, performance, safety, or intended use triggers a new UDI-DI, not just a new UDI-PI.

Why these five and not others

Tibor has audited UDI readiness at more MedTech startups than he can count, and the same five mistakes show up again and again. Not because founders are careless, but because the UDI system looks simple on first reading and reveals its edges only when a Notified Body auditor starts pulling threads. The five mistakes below are the ones that cost money to fix late, the ones that reliably surface in the audit opening meeting, and the ones that a founder who reads Articles 27 to 29 carefully can avoid before the first label is printed.

This post is a listicle, not a narrative. Each mistake gets its own section with the article it violates, a concrete example, and the fix. If you want the conceptual orientation to the UDI system as a whole, start with What is UDI? and then read MDR Articles 27 to 29 decoded. The consolidated readiness list is in the EUDAMED and UDI compliance checklist.

Mistake 1. Wrong issuing entity for the device family

The violation. MDR Article 27(2) requires manufacturers to assign UDIs according to the rules of an issuing entity designated by the European Commission. The Commission has designated four: GS1, HIBCC, ICCBBA, and IFA. A startup can pick any of the four, but the choice is not neutral. Each entity has its own allocation rules, its own fee structure, its own data carrier conventions, and its own industry footprint. Choosing the wrong one is not a legal breach on day one. The UDI is still valid. But it becomes a commercial and operational problem later, and switching after devices are in the field requires a full UDI migration, a label change, an EUDAMED update, and a coordinated notification to customers and distributors.

How it shows up. A founder picks HIBCC because an early advisor used it at their previous FDA-focused company, then discovers that the European hospital distributors they want to sell into run their scanning and procurement systems on GS1 standards. Or a founder picks IFA for the German market, then wins a pan-European tender and discovers that IFA identifiers are not the default format the hospital systems in other countries expect. Or a startup working on a device intimately connected with cells or tissues picks GS1 by default and later learns that ICCBBA is the entity designed for products of human origin and that ICCBBA identifiers carry metadata their category actually needs.

The fix. Make the issuing entity decision deliberately and early. For a pan-European startup building a new device with no specific reason to go elsewhere, the default is GS1. It is the most widely used, the best supported by hospital scanning infrastructure, and the least likely to create downstream friction. Deviate from the default only with a documented reason: existing HIBCC footprint in a US parent, ICCBBA scope for cells/tissues/blood, IFA for a strongly German-focused portfolio. Document the reason in the QMS so the next auditor does not ask the same question you already answered. The decision framework is in Choosing a UDI issuing entity: GS1, HIBCC, ICCBBA, IFA.

Mistake 2. Basic UDI-DI confusion with UDI-DI

The violation. MDR Article 2(15) defines the Basic UDI-DI as the primary identifier of a device model and the main access key for information stored in the UDI database. Article 29(1) requires the manufacturer to assign a Basic UDI-DI and submit it to the UDI database before placing the device on the market. The Basic UDI-DI is the grouping identifier. One per device family defined by intended purpose, risk class, and essential design and manufacturing characteristics. The UDI-DI is the carrier-level identifier, one per variant and packaging level. They are not interchangeable, and they appear in different places: the Basic UDI-DI appears in the technical documentation, on the EU declaration of conformity, on the Notified Body certificate, and in the EUDAMED entry; the UDI-DI appears on the label as part of the UDI carrier, alongside the UDI-PI.

How it shows up. A founder reads Article 2(15), assumes "Basic UDI-DI" is a plainer form of UDI-DI, and prints the Basic UDI-DI onto the label in place of the UDI-DI. Or a founder creates a separate Basic UDI-DI for every package size and variant, producing dozens of Basic UDI-DIs where the Regulation expects one per device family. Or a founder uses the UDI-DI on the certificate application and leaves the Basic UDI-DI field blank, which the Notified Body flags on receipt and which delays the submission by weeks.

The fix. Build the mental model once and write it down. The Basic UDI-DI is the trunk. One per device family. The UDI-DIs are the branches. One per variant and packaging level. The UDI-PIs are the leaves. One per lot, serial, software version, manufacturing date, or expiry. The technical file, the declaration of conformity, the certificate, and the EUDAMED entry all speak in Basic UDI-DIs. The label carries the UDI-DI plus the applicable UDI-PI elements. The operational walkthrough is in How to assign a Basic UDI-DI and the worked examples are in UDI-DI versus UDI-PI in practice.

Mistake 3. Missing or unreadable AIDC carrier on the label

The violation. Annex VI Part C of the MDR specifies the UDI carrier requirements. The UDI. UDI-DI plus the applicable UDI-PI elements. Must be placed on the label of the device and on all higher levels of packaging. The carrier must be machine-readable using an AIDC (Automatic Identification and Data Capture) technology, typically a linear barcode or a GS1 DataMatrix, and must be accompanied by a human-readable interpretation (HRI) unless space constraints are justified. Missing the AIDC carrier, printing it at a resolution below the scannability threshold, placing it where it cannot be scanned without obscuring other required label content, or omitting the HRI without documented justification are all Annex VI Part C violations.

How it shows up. A label designer compresses the DataMatrix to fit a crowded label and the resulting carrier fails scanning verification at the Notified Body audit. Or the HRI is dropped to make room for marketing copy. Or the UDI carrier is placed only on the primary unit and not on the outer carton, missing the Annex VI Part C requirement that UDIs appear at all higher packaging levels. Or the label prints the UDI-DI and UDI-PI in human-readable form but forgets the machine-readable carrier entirely.

The fix. Treat the UDI carrier as a Stage 1 label design constraint, not a late-stage addition. Get the carrier format locked with the chosen issuing entity (for GS1, this usually means GS1 DataMatrix with application identifiers for the UDI-DI and each UDI-PI element). Run label verification with a calibrated scanner before the label goes to the print-run approval. Confirm that every packaging level has its own UDI-DI and its own carrier. Keep the HRI present unless you have a documented space constraint that survives auditor scrutiny. The detail on carriers is in UDI carriers: barcodes, DataMatrix, and direct marking.

Mistake 4. EUDAMED entry incomplete

The violation. MDR Article 28 establishes the UDI database within EUDAMED and specifies that it holds the data elements listed in Annex VI Part B for every Basic UDI-DI and UDI-DI. Article 29(1) requires the manufacturer to submit those data elements before placing the device on the market, and Article 29(3) requires the manufacturer to keep them up to date. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 sets out the detailed rules for how EUDAMED. Including the UDI database module. Operates. An incomplete EUDAMED entry means one or more of the Annex VI Part B data elements is missing, wrong, or not kept current after placing on the market.

How it shows up. A founder submits the device entry, fills in the obvious fields, and leaves several Annex VI Part B elements blank because they did not recognise them as mandatory. The presence of substances of concern field, the URL to the electronic instructions for use, the Notified Body identification number. Or the entry is submitted on time but never updated after the first substantive change to the device, leaving an Article 29(3) maintenance gap that the next surveillance audit finds. Or the Single Registration Number referenced in the entry belongs to a legal entity that has since changed name or address, and the entry was never reconciled.

The fix. Build a one-to-one checklist of every Annex VI Part B data element and confirm each one before submitting. Write down which internal system holds the authoritative value for each field so the next update is mechanical. Set a recurring review. At minimum once per year, and immediately whenever a design change, a label change, an IFU change, a Notified Body change, or a manufacturer detail change happens. To re-check the entry against the current device state. The full Annex VI Part B walkthrough is in Device registration in EUDAMED.

Mistake 5. Software UDI not updated on significant change

The violation. Annex VI Part C of the MDR sets out the specific rules for when a new UDI-DI is required for software. A new UDI-DI is triggered whenever a software modification 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 revisions that do not affect those elements may retain the existing UDI-DI but require a new UDI-PI reflecting the new software version. Treating every software release as a UDI-PI change when the change is actually significant enough to require a new UDI-DI is an Annex VI Part C violation.

How it shows up. A SaMD startup ships a release that adds a new data interpretation feature, bumps the version number, updates the UDI-PI accordingly, and keeps the UDI-DI unchanged. The Notified Body, on the next surveillance audit, reads the change control record, recognises that the new feature affects the interpretation of data, and flags that the release should have triggered a new UDI-DI and a corresponding new Annex VI Part B submission under Article 29. The fix is no longer a future design decision. It is a retroactive correction that touches the change control record, the EUDAMED entry, the technical file, and the "about" screen inside the shipped product.

The fix. Write the UDI-DI trigger criteria from Annex VI Part C into your software change control procedure. Every change control review asks the explicit question: does this change affect original performance, safety, intended use, data interpretation, or any other identification-related aspect? If yes, the change requires a new UDI-DI, a new Annex VI Part B submission, and a new entry on the "about" screen. If no, a new UDI-PI is enough. Document the decision in the change control record so the auditor can see the question was asked. Assign the Basic UDI-DI, UDI-DI, and software version as machine-readable fields in the product (API, log output, or "about" screen metadata) so automated verification is possible at audit time.

The Subtract to Ship angle

The five mistakes above share a property that the Subtract to Ship framework for MDR treats as a signal. They are all caused by doing the wrong thing in the wrong order, not by doing too little work. A startup that sprints through UDI at the end of the project, under audit pressure, produces all five of these mistakes reliably. A startup that treats UDI as a Stage 1 design constraint. Issuing entity chosen before label design, Basic UDI-DI strategy defined before the technical file is written, AIDC carrier verified before the first print run, Annex VI Part B fields mapped before EUDAMED submission, software UDI-DI trigger criteria written into change control before the first release. Produces none of them.

The subtraction move is to remove every UDI activity that is not one of the steps Articles 27, 28, 29, Annex VI Part C, or (EU) 2021/2078 explicitly require, and to put the remaining steps in the correct order at the correct stage of the project. Parallel UDI schemes, speculative RFID projects on top of the mandatory carrier, custom databases that replicate EUDAMED fields, and "UDI governance workshops" that do not end with a concrete Basic UDI-DI decision all come out. What remains is short, finite, and auditable.

Reality Check. Are you making any of these five mistakes?

  1. Have you chosen a UDI issuing entity under Article 27(2), and can you state the specific reason why that entity suits your device type and commercial geography?
  2. Can you draw the Basic UDI-DI / UDI-DI / UDI-PI tree for your device family, and does the Basic UDI-DI appear in your technical file, your draft declaration of conformity, and your Notified Body application?
  3. Has your label been scanner-verified for the AIDC carrier, at every packaging level, with a documented HRI present?
  4. Have you mapped every Annex VI Part B data element to an internal authoritative source, and is your EUDAMED entry submission complete before the device is placed on the market?
  5. Is the Annex VI Part C trigger question for new UDI-DI written into your software change control procedure, and does every change control record answer it explicitly?
  6. Do you have a recurring review process to keep the EUDAMED entry current under Article 29(3)?
  7. If the Notified Body opened your UDI package tomorrow, would they find the Basic UDI-DI on the certificate, the UDI-DI on the label, and the Annex VI Part B data in the database, all agreeing with each other?

If you cannot answer five of these cleanly, one of the five mistakes is present in your project right now.

Frequently Asked Questions

What is the most common UDI mistake startups make under MDR? The most common is confusing the Basic UDI-DI with the UDI-DI. The Basic UDI-DI is the grouping identifier defined in Article 2(15) that sits above the UDI-DI and appears in the technical file, on the certificate, and in the EUDAMED entry. The UDI-DI is the carrier-level identifier that appears on the label together with the UDI-PI. Putting the wrong one in the wrong place breaks the link between the documentation and the database.

Can a startup change its UDI issuing entity later? Yes, but the change is expensive. Switching from one Commission-designated issuing entity to another requires reassigning UDI-DIs, reprinting labels, updating the EUDAMED entries under Article 29(3), and coordinating with customers and distributors. The practical recommendation under Article 27(2) is to make the choice once, early, with a documented reason.

What does Article 29(1) require a manufacturer to do before placing a device on the market? Article 29(1) requires the manufacturer to assign a Basic UDI-DI and submit it to the UDI database together with the other core data elements referred to in Annex VI Part B, in accordance with the rules of the issuing entity referred to in Article 27(2). The submission must happen before the device is placed on the market.

When does a software change require a new UDI-DI rather than a new UDI-PI? Annex VI Part C of the MDR requires a new UDI-DI whenever a software modification 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 revisions that do not affect those elements can retain the existing UDI-DI and receive a new UDI-PI reflecting the new software version.

Does the UDI carrier need to appear on every packaging level? Yes. Annex VI Part C requires the UDI carrier to appear on the label of the device and on all higher levels of packaging. Each packaging level carries its own UDI-DI. For reusable devices, direct marking of the device itself is required unless the specific exclusions in Annex VI Part C apply.

Where are the EUDAMED data elements for the UDI database specified? In Annex VI Part B of the MDR. The database itself is established by Article 28, the submission obligation sits in Article 29(1), and the detailed functioning rules are in Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 27 (Unique Device Identification system), Article 28 (UDI database), Article 29 (registration of devices), and Annex VI Part C (the UDI system, including the rules on UDI carriers, direct marking, and when a new UDI-DI is required). 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?. If you recognise more than one of these mistakes in your current UDI plan, read this post alongside What is UDI? and MDR Articles 27-29 decoded and work through the EUDAMED and UDI compliance checklist in order.