UDI Data Quality Under EU MDR: Where Basic UDI-DI Errors Actually Surface

Under EU MDR Article 27 and Annex VI Part C, every device carries two distinct identifiers: a Basic UDI-DI that never appears on a label, and one or more UDI-DIs that do. Most regulatory teams can recite that distinction. Far fewer have a reliable, documented answer for the question it actually turns on — which device changes trigger a new UDI-DI without disturbing the Basic UDI-DI above it — and that gap is where UDI data quality actually breaks down.

Two identifiers, two jobs

The Basic UDI-DI is the access key: it is what appears on the EU Declaration of Conformity, in the technical documentation, and on certificates, and it is what EUDAMED uses to group everything that belongs to one device model or family. The UDI-DI is the traceable unit: it identifies one specific device configuration and packaging level, is encoded in the UDI carrier alongside the variable UDI-PI (lot, serial number, expiry), and appears on the physical label. A single-unit pack and a bulk pack of the same device carry different UDI-DIs but share one Basic UDI-DI. Getting that relationship right in the technical file is core design controls and technical documentation work, not a separate registration exercise bolted on afterward.

The changes that actually force a new UDI-DI

MDCG 2022-7 sets out the change triggers directly, and they are narrower than most teams assume:

• Name or trade name. A rebrand or trade-name change on an existing device triggers a new UDI-DI.
• Version or model. A new device version or model — not a minor manufacturing tweak — requires its own UDI-DI.
• Sterilization status. A change between sterile and non-sterile presentations of the same device requires a new UDI-DI.
• Quantity of devices in a package. Repackaging into a different unit count is a labeling change that carries its own UDI-DI.
• A warning or contraindication that affects risk. A labeling change of this kind requires a new UDI-DI even where the physical device is unchanged.

The Basic UDI-DI almost never changes. The UDI-DI changes constantly, and every miss is a live label, technical file, or EUDAMED record that no longer says the same thing. Why the reconciliation, not the definition, is the risk

Where the data actually goes wrong

The definitions are rarely the problem; the reconciliation across systems is. A labeling change ships with a new UDI-DI assigned by the labeling team but never reflected in the technical documentation or the EU MDR & IVDR compliance file the QA function maintains. A device family gets split across inconsistent Basic UDI-DIs when variants that should share one grouping are registered separately — or the reverse, where genuinely distinct models are folded under one Basic UDI-DI that should have been split. And because EUDAMED's Device module is only part of a wider registration sequence — see EUDAMED's staged mandatory-use timeline for how that module fits into the broader schedule — a UDI record that was correct at initial registration quietly drifts out of sync with the technical file as the device evolves, and nobody notices until an audit or a notified body review asks for the reconciliation directly.

None of this is exotic. It is a bounded reconciliation exercise: a Basic UDI-DI mapping review, a change-trigger checklist wired into labeling change control, and a standing owner for keeping the technical file, the Declaration of Conformity, and EUDAMED describing the same device the same way. Manufacturers who treat UDI as a one-time registration event are the ones who find the gap during a notified body audit. Our UDI & GUDID compliance work exists to close it before that happens.