UDI-DI vs UDI-PI

The UDI-DI is static: it changes when a new version, model or package configuration is introduced. The UDI-PI is dynamic: it changes with each lot, serial or date.

Together they appear in human-readable and automatic identification and data capture (AIDC) form, such as a barcode.

In the US, the device identifier is submitted with device attributes to the Global Unique Device Identification Database (GUDID). Each package level, such as unit, box and case, may have its own DI.

Changes that trigger a new DI are defined by FDA and the issuing agency rules.

Production identifiers include lot or batch, serial number, expiration date, manufacturing date and, for HCT/Ps regulated as devices, a distinct identification code, as applicable to the label.

PI data is not stored in GUDID; it lives in manufacturer and distribution records.

UDIs are issued under FDA-accredited issuing agencies such as GS1, HIBCC and ICCBBA, each with its own syntax. GS1 application identifiers, for example, separate GTIN, lot, serial and dates.

Pick a format that customers and distribution systems can read.

Under EU MDR and IVDR, the Basic UDI-DI is a higher-level identifier used in regulatory documentation and EUDAMED to group devices with the same intended purpose, risk class and design characteristics. It does not appear on the label.

Do not confuse Basic UDI-DI with the UDI-DI printed on packaging.

Label content must match the approved artwork and data. Verifying barcode quality and data content at the line prevents unreadable or wrong codes reaching customers.

Reconcile printed labels and rejected labels per lot.

Mistakes include reusing a DI after a significant change, PI fields that do not match batch records, barcodes failing grade checks, and inconsistent package-level hierarchies.

Data errors in GUDID or EUDAMED can propagate to hospitals and distributors.

V5 label and traceability features can print labels carrying lot, serial and expiry data from production records and link shipments to lots, supporting consistency between the UDI-PI and batch records.

V5 does not submit records to GUDID or EUDAMED or assign DIs; regulatory and labelling teams own those.

Pick one device family and confirm that every package level's DI, the PI fields printed, and the batch record values match for a recent lot.

Check that a scan at a distributor would return the same data.

Each level of packaging that is a unit of sale or distribution may carry its own UDI-DI, with GUDID recording quantities per package. The hierarchy lets hospitals and distributors scan any level.

Shipping containers are generally excluded from UDI requirements, but logistics labelling may still use similar codes.

FDA requires dates on device labels to use a specified format, and the human-readable UDI must match the barcode content. Mismatches are common audit findings.

Verify both at the line and during label artwork approval.

Some devices have exceptions or alternative placements, and reusable devices that are reprocessed may need direct marking of the UDI on the device. Check the rules for each device.

Direct marking requires durable methods and verification of readability after reprocessing.

A catheter's unit pouch carries a GS1 barcode containing the GTIN (the UDI-DI), lot number and expiry date (the UDI-PI). A box of ten has a different GTIN for the box level.

When the catheter's coating changes enough to require a new version, the company assigns new DIs and updates GUDID, while lot and expiry continue to vary with production.

Most UDI problems appear at the label printer, not in the database. The static device identifier must match the packaging level, and the production identifiers must match the lot or serial number actually being packed.

• Confirm the DI belongs to the exact packaging configuration, such as unit, box or case.
• Pull lot, serial, manufacture and expiry dates from the production record rather than typing them.
• Verify both the human-readable text and the barcode, and check barcode grade where required.
• Reconcile labels printed, used and destroyed at the end of the run.
• Hold product if the printed PI does not match the record and investigate before release.
• Update the device database entry when a change triggers a new DI, before the new label is used.

Line clearance between products should include removing old label stock and confirming the printer template, so the wrong DI cannot carry over into the next run.

1. Confirm the applicable requirement, product scope and decision owner.
2. Map the current method and the records already available.
3. Define terms, responsibilities, evidence and exception handling in the approved procedure.
4. Pilot the method on one representative process and challenge a difficult exception.
5. Train affected roles, approve the change and monitor whether the method works as intended.
6. Review after significant change and retain a transparent history of decisions.

Scale the formality to risk and complexity. A small operation still needs clear responsibilities and reconstructable evidence, while a multi-site operation also needs harmonised definitions, governance and comparison rules.

• Can a reviewer identify the source, owner, method and current approved version?
• Do summaries reconcile to original records and include unfavourable or missing evidence?
• Are exceptions visible, assessed and linked to the affected material, product or process?
• Are actions assigned, overdue items escalated and effectiveness reviewed?
• Have changes in product, supplier, equipment, method or regulation triggered reassessment?
• Does the record distinguish system support from the decision an authorised person made?

• Approved scope, definitions and responsibilities for UDI-DI vs UDI-PI.
• Source records and identifiers that let a reviewer reconstruct the work.
• Methods, assumptions, calculations, exclusions and any data-quality limitations.
• Exceptions, investigations, decisions, approvals and resulting actions.
• Version history showing when the approach changed and why.

Records should be proportionate to the decision and usable by someone who was not present. Preserve original evidence and corrections rather than replacing it with an unexplained summary.

• Can users trace every summary value back to its source record and version?
• How are roles, permissions, signatures and corrections recorded?
• Can the workflow reflect our approved procedure without inventing a universal rule?
• What happens during an outage, and how are later entries distinguished?
• Can we test the highest-risk exception with realistic data before committing?
• Which decisions remain explicitly assigned to an authorised person?