UDI and Traceability — the Backbone of Modern Device Vigilance

This module closes its device-vigilance content with the infrastructure that makes everything in Lessons 14.8 through 14.10 actually actionable at the individual-unit level: Unique Device Identification. A UDI is a standardised, machine-readable identifier assigned to a specific medical device, functioning as the device-world equivalent of the precise, traceable identifiers this course has built for drugs throughout — a specific MedDRA code (Module 4), a specific batch in a PBRER’s exposure data (Module 8), a specific case number in a safety database (Module 10).

A UDI carries two distinct components, and understanding the difference matters for exactly the same reason distinguishing a PT from an LLT mattered in Module 4: a Device Identifier (DI) is the fixed part, identifying the specific device model or version — analogous to a Preferred Term, stable across every unit of that model. A Production Identifier (PI) is the variable part, capturing the specific lot number, batch, serial number, or expiration date of an individual unit — analogous to the specificity an LLT provides, unique to the actual item in question rather than the general category it belongs to.

This level of specificity is what makes a genuinely targeted device recall possible, rather than a blunt, product-line-wide response. If a manufacturing defect is traced to a specific production run, UDI data allows a recall — or a corrective action — to target exactly the affected units, rather than pulling an entire device model from the market when only a specific batch was actually compromised. This mirrors precisely the batch-level precision drug recalls depend on, and it’s the reason device incident investigations increasingly start with the question "which specific UDI was involved" rather than "which device model."

UDI data feeds directly into the reporting infrastructure Lesson 14.9 covered — EUDAMED and MAUDE both incorporate UDI data into their incident records, and a device’s technical documentation (the materiovigilance rough equivalent of the PSMF Module 11 built) is organised around UDI-traceable production data. Without reliable UDI implementation, an incident report risks becoming exactly the kind of untraceable, unactionable finding Module 10’s duplicate-detection and audit-trail lessons warned against for case data — a real signal that exists in the system but can’t actually be traced back to a specific, correctable production batch.