Beyond UDI: What a Device Identifier Is Worth After the Audit

A UDI is more than a compliance requirement. It gives your installed base a stable identity that can support service history, documentation control, warranty status and field safety corrective action scoping.

Beyond UDI: What a Device Identifier Is Worth After the Audit

A UDI is required for registration, but its lasting value is that it gives every device model one identity that regulatory, service, sales and manufacturing can share, and, where a serial number is part of it, every unit. Used beyond registration, it makes safety notices faster to scope, ties manuals to the right model and version, and keeps service history and warranty status attached to the device.

Most manufacturers assigned UDIs because a regulator required it. The project had a deadline, a budget, a sign-off, and then it was done.

What usually does not happen next is anyone asking what the identifier is now good for.

It is worth asking, because in a lot of companies the UDI is the first stable, unambiguous way of naming a device version, and for serialised devices an individual unit, that the organisation has ever had. Sales had part numbers, service had customer references and manufacturing had lot numbers, and none of them agreed with each other. The regulator effectively forced a common name onto the thing, and that name is worth more than the filing it was created for.

One precision matters. The UDI-DI names a model and version. Whether the full UDI names a single unit depends on the production identifier: a serial number does, a lot or batch number names a group. Most of what follows works at either level, but unit-level service history needs serialisation. The Commission's UDI pages set out the rules.

The regulation splits the two explicitly:

"a UDI device identifier ('UDI-DI') specific to a manufacturer and a device, providing access to the information laid down in Part B of Annex VI [and] a UDI production identifier ('UDI-PI') that identifies the unit of device production and if applicable the packaged devices, as specified in Part C of Annex VI."

Article 27(1)(a) of Regulation (EU) 2017/745. The model is named by the UDI-DI. Whether the individual unit is named at all depends on what the UDI-PI carries.

1. A field safety corrective action stops being a research project

The realistic test of installed base knowledge is a safety notice. Units built between two dates, with a specific option fitted, need an action.

Without device-level identity, answering that means reconciling shipment records, service history and whatever the regional teams remember. Companies budget days for it. Some budget weeks.

With UDI-level records that are actually maintained, it is a query. The difference is not administrative comfort. A recall that takes a week to scope is a week during which affected devices remain in use.

2. Service documentation gets attached to the right revision

This one gets less attention than it deserves. A UDI-DI exists to distinguish device models and versions, which means it can also answer the question service teams get wrong constantly: which manual applies to this unit.

A technician working from the current published manual on a device three revisions behind is following the wrong procedure with full confidence. Tying documentation to the device identifier rather than to the product line removes that failure mode, and it is the mechanism behind resolving cases at the device instead of escalating them. We covered how that plays out in practice in what happens when a device has its own address.

3. Service history becomes an asset record rather than a ticket archive

Ticketing systems organise by ticket, which suits the service desk and does nothing for the device. When every case is filed against the device identifier, the unit accumulates a history. The next person to touch it sees what the last one did. Patterns become visible per configuration rather than per customer, which is how you find out that a particular build has a recurring failure before the complaints arrive.

For a sense of scale on device-level service in general: a US medtech distributor cut total service costs by 27% and halved resolution time on sqanit. That figure is the total effect of the deployment, not of UDI-linked history alone.

4. Contracts and warranty attach to the unit, not to the invoice

Most warranty and service contract data lives against a sale. A device that was resold, moved between sites within a hospital group, or swapped in as a loaner tends to lose its commercial status somewhere along the way.

Against a device identifier, the status travels with the unit. That makes two things possible: not doing warranty work you were not obliged to do, and knowing which units are out of contract and worth an offer.

Service attach rate is the number most OEMs say they want to improve. It is hard to improve a rate when you cannot list the denominator.

The obligation is not the point

Assigning a UDI, registering in EUDAMED or GUDID, and maintaining those records is a regulatory obligation you meet through your quality system and your regulatory affairs team. No service software discharges that obligation, and any vendor telling you otherwise is selling you a problem. The current requirements for manufacturers are set out in what manufacturers must do before November 2026, and the separate obligations of importers and distributors in the role-by-role version.

What the obligation produces is a clean, regulator-backed identity for every device model you have ever placed, and for every unit where a serial number is part of it. The organisations getting value out of the last three years of regulatory work are the ones who noticed that and built service on top of it.

The ones who filed it and moved on paid the full cost and collected one of the benefits.

Where to start if you want to test this

Do not start a programme. Take one product line and run one exercise.

Pick twenty units from that line, at random, from at least two years ago. For each one, write down:

  • Current location and operator
  • Current revision and configuration
  • Date and content of the last service event
  • Contract or warranty status today

Time it. Note how many sources you had to touch, and how many you could not answer at all.

That sheet is your business case. It is also, usually, an uncomfortable meeting.

Run the twenty-unit exercise above and bring us the sheet. We will show you what it looks like solved.

FAQs

Frequently asked questions.

01.

What is a UDI used for besides regulatory registration?

It gives every device a unique, unambiguous identity that all departments can agree on. That makes it usable as the key for service history, documentation versioning, contract status and field safety corrective action scoping. The regulatory registration is the obligation; the identifier is the by-product worth building on.

02.

Does UDI-level service documentation help with audits?

It helps you produce evidence faster, because service events are filed against the same identifier the regulator uses. It does not replace your quality management system or your regulatory processes, and no service software discharges a regulatory obligation on your behalf.

03.

What is the difference between a UDI-DI and a UDI-PI?

The device identifier (UDI-DI) identifies the model and configuration. The production identifier (UDI-PI) identifies the specific production run, such as lot, serial number and manufacturing date. Service work that needs to distinguish individual units depends on the production identifier.

04.

How does UDI relate to field safety corrective actions?

Safety notices are scoped by device and production characteristics, which is exactly what UDI encodes. If your service and distribution records are filed against UDI, scoping an affected population becomes a query. If they are not, it becomes a reconciliation exercise across several systems.

05.

We already registered everything. What is left to do?

Check whether anything downstream of registration uses the identifier. In many companies the UDI exists in regulatory systems and nowhere else, while service, documentation and contracts still run on their own references. That gap is where the unclaimed value sits.