Medical device traceability: UDI, GS1 and what regulation requires

What tracing a medical device actually means

Tracing a device is not knowing how many units sit in the warehouse. It is being able to answer three questions about one specific unit: where it came from, where it has been and who it was used on.

That capability becomes critical in the worst case. When a manufacturer recalls a lot, a hospital with traceability identifies within minutes which units of that lot remain in stock and which patients received the ones already implanted. A hospital without traceability goes through folders.

• Identification: every unit carries a code that sets it apart from the rest
• Path: every movement is recorded with date, place and owner
• Use: consumption is linked to the procedure and the patient
• Reconstruction: the history can be recovered later, not only viewed live

UDI: how the identifier is built

UDI, Unique Device Identification, is the international framework that standardises how a medical device is identified. A UDI code has two parts, and that split explains almost everything.

The device identifier, DI, is the fixed part: it identifies the manufacturer and the model. It is the same across every unit of that reference.

The production identifier, PI, is the variable part: lot, serial number, expiry date and manufacturing date, depending on the device type. It is what tells one unit from another.

Without a PI there is no lot or expiry traceability. A system that reads only the DI knows which product it holds, not which unit.

UDI is expressed in two simultaneous formats: one machine readable, the barcode or the RFID tag, and one human readable, printed on the package. Both must match.

GS1 in practice: GTIN, application identifiers and DataMatrix

GS1 is one of the accredited issuing agencies for UDI codes and the most widespread standard across the clinical supply chain.

The GTIN is the number identifying the trade item and, in most cases, plays the DI role within the UDI.

Application identifiers are the bracketed prefixes that structure the remaining data. They are the reason a reader can interpret a long string with no ambiguity.

• (01) GTIN: which product it is
• (17) expiry date
• (10) lot number
• (21) serial number

On small devices the usual standard is GS1 DataMatrix, a two dimensional code that fits within a few millimetres. In UHF RFID, the SGTIN scheme encodes the GTIN together with the serial number inside the tag, so the unit is identified without reading the package.

Traceability is not the same as inventory

This confusion is the most frequent cause of projects that stall halfway. An inventory system answers how much there is. A traceability system answers which one it is and where it has been.

The difference is granularity. Inventory works on references and quantities: twelve units of a given catheter. Traceability works on individual units: this unit, from this lot, expiring on this date, used in this procedure.

A hospital ERP usually handles inventory well and is not designed for the unit. That is why traceability is implemented as a layer that captures the event at the point of use and then hands the ERP the consolidated consumption it expects to receive.

What regulation requires

The UDI framework has been adopted in stages across the main markets, on separate calendars and generally by device risk class. The pattern repeats across jurisdictions: first the product must arrive identified and documented, then the facility must keep a record of that data, and finally that record must be linkable to the patient.

The distinction that matters most to a hospital is who carries the obligation. In most frameworks the requirement starts with the manufacturer and reaches the facility through the data it must receive and keep. The European Union and Chile go one step further and bind the provider directly.

For an operation supplying more than one country, the practical conclusion is to capture the complete data set from the start. Recording lot and expiry costs the same as recording quantity alone, and it avoids redoing the process every time a local requirement changes.

Traceability regulation country by country, with deadlines and databases

How to implement it without slowing clinical work

The friction point is always the same: recording competes with care. If tracing requires someone to type a lot number while the procedure moves on, the record is postponed and later completed from memory.

That is why the design rule is that the event must capture itself, at the moment it happens. The cabinet that registers the withdrawal, the portal that registers the exit and the reader that registers the count all generate data without adding a task for the clinical team.

• Start with the families where lot and expiry carry real consequences: implants, high cost devices, consignment
• Require the supplier to deliver traceability data on the delivery note or invoice, not in a separate email
• Clean up master data before installing anything: one badly loaded reference carries the error through the entire history
• Define what happens when something arrives unidentified, because it will
• Integrate consumption into the clinical system and the ERP, so the record serves billing and replenishment, not only compliance