The Workbench · Craft
One UDI never touches the label at all
A UDI record built around one identifier per device is missing half of what MDR Article 27 actually assigns. This blog has already traced the US side of unique device identification, where 21 CFR 830.20 pairs a device identifier with a production identifier — lot, batch, serial, or dates — both meant to sit together on the label. MDR draws its split somewhere else entirely. Article 27 and the definition at Article 2(15) hand a device two identifiers at two different altitudes, and only one of them is ever meant to touch the physical product.
The identifier that goes on the device, and the one that doesn't
Article 27(1) requires devices, other than custom-made or investigational devices, to carry a UDI carrier on their label and packaging, assigned in accordance with the UDI system set out in Part C of Annex VI. That carrier encodes a UDI-DI — specific to a manufacturer and a device at a given packaging level — alongside a production identifier where the device carries one. Article 2(15) defines a second identifier sitting above it: the Basic UDI-DI, “the primary identifier of a device model,” and the main key used in records and in the European database, EUDAMED. The Basic UDI-DI is not printed on the label, the packaging, or the device itself. It lives in the technical documentation, on the EU declaration of conformity, and on the notified body's certificate — a model-level reference the UDI-DI on the shelf never has to carry.
Not the same split the US system draws
It's worth being precise about what doesn't transfer here. 21 CFR 830.20's device-identifier-plus-production-identifier pair both sit on the same label, describing the same physical unit at two levels of specificity — which version, and which particular lot or serial. MDR's Basic UDI-DI and UDI-DI aren't that. A UDI-DI still identifies a specific packaging configuration the way the US device identifier does, but the Basic UDI-DI sits a level above both of them, grouping devices that share a common identity rather than describing a single package more precisely. Reading one system's structure onto the other is the mistake a UDI record built by an EU and a US team working from the same template can quietly make.
What actually forces a new Basic UDI-DI
Part C of Annex VI ties multiple UDI-DIs to a single Basic UDI-DI as long as the devices share the same intended purpose, risk class, and essential design and manufacturing characteristics — different pack sizes or configurations of the same device model can sit under one Basic UDI-DI even though each carries its own UDI-DI. Change any one of those three things — a new intended purpose, a shift in risk classification, a design or manufacturing change substantial enough to count as essential — and a new Basic UDI-DI is owed, not just a new UDI-DI. A change log that tracks UDI-DI reissuance on every labeling update but never asks the Basic UDI-DI question has only checked the identifier that changes often, not the one that's supposed to stay stable until the device itself genuinely becomes a different model.
Where the Basic UDI-DI actually has to show up
Because the Basic UDI-DI is the record's main key rather than a label element, it surfaces in the same documents a design file has to structure around Annex II — the technical documentation itself, the EU declaration of conformity, and, where one applies, the notified body's certificate. A technical file that carries a UDI-DI on every device photo and packaging drawing but never states the Basic UDI-DI those variants roll up to hasn't actually built the EUDAMED-ready record Annex VI Part C describes; it's documented the packaging without documenting the model.
Where this meets the rest of the file
A UDI record built around both identifiers — the UDI-DI and production identifier the label carries, and the Basic UDI-DI the technical documentation and declaration of conformity carry instead — is previewed in the launch catalog. If your team tracks the Basic UDI-DI / UDI-DI split differently, the shelf takes that correction directly.
The Regulatory Toolkit launches soon — a free shelf of source-mapped templates, checklists and browser-only tools for regulatory teams. Get one email when it opens, or contribute a template.