30 July 2026
Sarah Burley
The UDI system was designed with the physical world in mind: shipping boxes, labels, barcodes, a scanner at the loading dock. But how does it work for AI and SaMD?
Software has multiple releases, semantic version numbers, and continuously updated AI models; these key differences can sometimes lead to manufacturers getting stuck. This blog uncovers what the UDI components actually are, why they exist, who is responsible for them, how and when to register them, and how to enable swift software releases whilst maintaining your UDI obligations.
Let’s start with the definitions
Before getting into the nitty-gritty, we need to understand the terms. The UDI is not a single code; it’s a small family of related identifiers that do different jobs.
Basic UDI-DI is the master identifier sitting above everything else, and each UDI-DI inherits the attributes of its linked Basic UDI-DI. It's the main key in EUDAMED and in your regulatory documentation (e.g. certificates, Declaration of Conformity etc.), connecting all devices with the same intended purpose, risk class, and essential design and manufacturing characteristics. Two quirks: it is independent of packaging and labelling, and it does not appear on any trade item. It lives in the paperwork and the database
UDI is the overall unique code, numeric or alphanumeric, assigned to a device to allow traceability and unambiguous identification on the market. The UDI is assigned at the system level. It’s made up of two parts: a device identifier (UDI-DI) and a production identifier (UDI-PI). Think of the UDI as the full “who and which batch” label; the DI answers “which device” and the PI answers “which production run”
UDI-DI (Device Identifier) is the part specific to a manufacturer and a device. It identifies a particular device model or packaging configuration, and it’s the key that links to that device’s record in the UDI database within EUDAMED. Crucially, a UDI-DI is associated with one, and only one, Basic UDI-DI
UDI-PI (Production Identifier) identifies the unit of device production. On a physical device this is your lot number, serial number, manufacturing or expiry date. For software, it is the version number
UDI carrier is the physical or electronic means of conveying the UDI (a barcode, or for software a plain-text string on a readable screen, or an API for software with no User Interface)
Issuing entity is the body you actually get your codes from. The Commission has designated four: GS1, HIBCC, ICCBBA, and IFA. You don't invent UDIs; you obtain them from one of these
Who is responsible for UDI assignment?
Per Annex VI and MDCG 2026-5, the manufacturer is responsible for:
Assigning and maintaining UDIs for its devices
Placing the UDI carrier on the device or its packaging
Making the initial submission and subsequent updates in EUDAMED
How do I ship software fast?
You might question whether, if software changes constantly, you will be minting new UDI-DIs every release. The answer is mostly no. It’s the size of the change that decides which identifier is affected.
A new UDI-PI is required only for minor revisions, such as bug fixes, non-safety usability tweaks, and security patches
A new UDI-DI is required for changes that alter the software's original performance, safety, interpretation of data, or name/version/warnings/UI-language. (MDCG 2018-5 gives examples like new or modified algorithms, database structures, operating platform, user interfaces, or architecture)
A new Basic UDI-DI is required for any change to the intended purpose, risk class, or essential design and manufacturing characteristics
So the rule of thumb: most releases move only the UDI-PI; a release that changes performance, safety, or data interpretation moves the UDI-DI; a release that changes the UDI-PI and/or the UDI-DI moves the UDI; and only a release that changes intended purpose, risk class, or essential characteristics moves the Basic UDI-DI. If your release process can reliably answer "which of those three did this build actually change?" before shipping, you've solved most of the problem.
How and when should UDIs be registered?
From 28 May 2026, the UDI/Device registration module in EUDAMED is legally mandatory, and new devices placed on the market must be registered before first market placement. See our blog for more detail on these steps.
In terms of which UDI changes need to be registered in EUDAMED:
Basic UDI-DI |
|
UDI-DI |
|
UDI-PI |
|
How should we assign UDIs to modular software?
The UDI is assigned at the system level of the software, to the object defined by its intended purpose, which is placed on the market. Certificate scope, Basic UDI-DI, and UDI-DI should all be aligned with what's actually sold.
If your product is a system of several component devices, the expectation (per MDCG 2019-9) is that each component gets its own Basic UDI-DI and the system gets one, but only where the system is a device in its own right under MDR Article 22(4), with the SSCP drawn at that system level. Separately CE-marked components that are merely compatible aren't a "system" in that sense, and keep individual Basic UDI-DIs.
In summary
UDI = UDI-DI + UDI-PI. For software, the UDI-PI is the version number
Basic UDI-DI is the master key in your documentation and certificates; it never appears on a trade item
New Basic UDI-DI if there’s a change to the intended purpose, risk class, or essential design and manufacturing characteristics
New UDI-DI only when a change affects performance, safety, or interpretation of data, or name/version/warnings/UI-language
Minor revisions (bug fixes, patches, non-safety usability) → new UDI-PI only. UDI-PIs don’t need to be registered
The manufacturer assigns UDIs via an issuing entity. The operations can be delegated to a third party, but liability can't
UDI/Device registration in EUDAMED is now legally mandatory, and new devices placed on the market must be registered before first market placement
The Basic UDI-DI must be assigned at the system level. If the product is a system of several devices, each one gets its own Basic UDI-DI as well as the system
Your change-evaluation process must be defensible